RFR: Bulk backport to sh/jdk8u

[Aleksey Shipilev]

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!

We may consider rehashing changing all of these later, all at once, though unlikely for the reasons
above.

Thanks,
-Aleksey