RFR: Remaining Shenandoah backports jdk/jdk -> sh/jdk11

Roman Kennke rkennke at redhat.com
Thu May 16 18:02:43 UTC 2019


>>>> This backports the following changes to sh/jdk11:
>>>>
>>>> JDK-8221751: Shenandoah: Improve SATB enqueueing
>>>> JDK-8221848: Shenandoah: ArrayCopy post-barrier improvements
>>>> JDK-8222227: Shenandoah: Fix Traversal GC weak roots handling in
>>>> final-traversal pause
>>>> JDK-8222259: Shenandoah: Pre-evacuate string-dedup roots in Traversal GC
>>>> JDK-8222188: Shenandoah: Adjust Shenandoah work gang types
>>>> JDK-8218468: Load barrier slow path node should be MachTypeNode
>>>> JDK-8223651: Build fails with --with-jvm-features=-jfr and
>>>> --disable-precompiled-headers
>>>>
>>>> Changes transplanted with minimal and simple changes.
>>>> Testing: hotspot_gc_shenandoah fine
>>>>
>>>> Ok?
>>>
>>> Okay. Is there a webrev that shows the changes, for the record?
>>
>> Oops, forgot to include it:
>>
>> http://cr.openjdk.java.net/~rkennke/backport-jdk11-2019-05-16/webrev.00/
> 
> *) The indenting is weird here in shenandoahBarrierSetAssembler_aarch64.cpp -- is it the same way in
> upstream?
> 
>   90   if (is_oop) {
>   91       Label done;
>   92
>   93       // Avoid calling runtime if count == 0
>   94       __ cbz(count, done);
>   95
>   96       // Is updating references?
>   97       Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset()));
>   98       __ ldrb(rscratch1, gc_state);
>   99       __ tbz(rscratch1, ShenandoahHeap::UPDATEREFS_BITPOS, done);
>  100
>  101     __ push(saved_regs, sp);
> 
> Otherwise looks fine.

Yes:
http://hg.openjdk.java.net/jdk/jdk/file/b6ee58ec8814/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp#l90

Want me to change it for 11 now?

Roman



More information about the shenandoah-dev mailing list