RFR: Bulk backport to sh/jdk8u

[Andrew Haley]

On 27/09/17 20:09, Aleksey Shipilev wrote:
> On 09/27/2017 07:33 PM, Andrew Haley wrote:
>> 5111   // During evacuation and evacuation only, we can have the stores of cset-values
>> 5112   // to non-cset destinations. Everything else is covered by storeval barriers.
>> 5113   mov(tmp1, ShenandoahHeap::evacuation_in_progress_addr());
>> 5114   ldrw(tmp1, Address(tmp1));
>> 5115   cbnzw(tmp1, done);
>>
>> Looks reasonable, but in jdk8 is evacuation_in_progress not a field in the
>> thread?
> 
> Yes, we can poll it off TLS, like the write barrier does. But for the checking/debugging code like
> this, it makes more sense to test the closest source of truth: the global heap variable, instead of
> going via optimized TLS flag. If TLS flag setter fails, then prior WB/storeval silently fails, and
> then this checking code will capture the inconsistency. IIRC, we did experience TLS setting failure
> once, this is when we beefed up on store checks!

OK, but such subtle reasoning demands a comment in the code.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671