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