RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning

Erik Österlund erik.osterlund at lnu.se
Sun Jun 14 00:25:23 UTC 2015

Hi guys,

Short story:
I talked to Dave Dice about my ADS implementation(s). He agrees my ADS is
“probably safe”, but explained that just fencing is probably preferred
over ADS for the future anyway due to current hardware trends of
optimizing fences.

Long story:
The motivation why fences are more attractive is that they are getting
faster and faster by letting CPUs speculate more about the execution over
fencing points, instead of waiting for the entire store buffer to
serialize. Instead it speculates and only restarts if speculative load are
invalidated before the stores that should have flushed at the fencing
checkpoint have been flushed. This way fences are getting significantly
cheaper as speculative windows continue to increase, whereas the
TLB-shootdown hardware doesn’t have as many good solutions for becoming
more scalable right now and can become expensive on multi-socket systems.
Therefore, it makes sense to use fences instead, because they seem to have
a brighter future with current hardware trends, and scale better.

Therefore, let’s go for fences! :)


Den 02/06/15 12:22 skrev Erik Österlund <erik.osterlund at lnu.se>:

>Hi Aleksey,
>Den 02/06/15 11:25 skrev Aleksey Shipilev <aleksey.shipilev at oracle.com>:
>>On 06/02/2015 10:44 AM, Andrew Haley wrote:
>>> Have we come to a complete standstill?
>>Appears to be so.
>>I am still uneasy about global_store_fence/mprotect trick, since I don't
>>quite believe it works without a hitch everywhere, even given Erik's
>>extensive explanation it "appears" to work fine. Erik, can you follow up
>>with Dave Dice on whether that is actually safe?
>Sure, will do.
>>The original StoreLoad patch by Andrew looks moderately okay to me,
>>given it is conditionalized for CMS (I wonder if it should be
>>conditionalized on CMSPrecleaningEnabled?). Google folks may chime in
>>saying it breaks the performance for them...
>I think the patch looks okay for now, and it¹s important to get a
>correctness fix although potentially suboptimal in terms of performance
>ASAP. I have a feeling the global_fence discussion could take a while
>before reaching a conclusion, don¹t know how long. It would be good to
>have the correctness fix while exploring better performant synchronization
>solutions to elide the fences.
>Yes, Google folks might say there are performance regressions then, but
>others might complain the JVM unexpectedly crashes now as it is now. I
>think this is worse.
>>Actually, GC guys should make this call.

More information about the hotspot-dev mailing list