RFR: Bulk integration from jdk/jdk 2018-04-23

[Roman Kennke]

Looks like I've messed up the merge (again). I fixed it by hg stripping
up to the merge changesets, fixing some whitespace stuff, hg commit
--amend the changes right into the same changeset. I think it should be
safe to push this.

Output of:
hg diff -r 49794:50054 src/hotspot/share/gc/shenandoah
src/hotspot/cpu/x86/gc/shenandoah

http://cr.openjdk.java.net/~rkennke/merge-2018-04-23/shenandoah-changes-02.patch

Some more notes:
- The merge also contained one other goodie: the even cleaner separation
of globals.hpp from GC globals.
- This fixed merge changeset also includes shenandoahThreadLocalData.hpp
which was missing from previous diff

I re-ran hotspot_gc_shenandoah fastdebug+release. I checked for no
missing files in workspace. I ran jcheck on it. Should be all good now.
Can you please check it too?

Thanks,
Roman


> On 04/23/2018 06:48 PM, Roman Kennke wrote:
>> This merges latest upstream changes, based on:
>>
>> changeset:   50053:69d7398038c5
>> user:        rehn
>> date:        Wed Apr 18 09:25:51 2018 +0200
>> summary:     8195099: Concurrent safe-memory-reclamation mechanism
>>
>> It brings lots of goodies, the top 3 being:
>>
>> - thread local GC data (replacing our gcstate, satb queue and
>> oom_during_evac, possibly in the future the gclab)
>> - runtime object equals barriers
>> - interpreter/assembler GC code generator
>>
>> The complete list of changes:
>> http://cr.openjdk.java.net/~rkennke/merge-2018-04-23/changesets
>>
>> Diff of Shenandoah changes:
>> http://cr.openjdk.java.net/~rkennke/merge-2018-04-23/shenandoah-changes.patch
> 
> Looks good. We better push this soon to see how it holds water. Ugh, I expect so many weird issues
> from this, and it moves Shenandoah code apart from backports. But, there is nothing we can do.
> 
> I have only one question: what is CompressedOops::is_null and friends? Is is a newfangled way to
> deal with compressed oops? Does it work on non-coops paths?
> 
> Thanks,
> -Aleksey
>