RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector
vladimir.kozlov at oracle.com
Tue Nov 27 21:36:34 UTC 2018
Good. Thank you for testing. I don't have any more question about build changes.
I will wait C2 changes.
About C2 nodes names:
>> Is it possible to reuse LoadBarrier by adding GC specific flag to it?
>> I am not against adding new nodes if really needed. My concern is about
>> using GC name in node's names.
> That would be very weird. Shenandoah's barrier is *not* a load barrier.
> GC's names in node name makes sense (to me) because the generated code
> is GC specific, and it's used in .ad files to match. I guess we could
> give it a more generic names (ReadBarrier, WriteBarrier,
> GCCompareAndSwap, ..) and then match them in .ad and call via
> BarrierSetAssembler to generate GC specific code. But it seems odd and
> hard to read+understand to me.
I got that you can't reuse exisitng nodes.
Sorry, but I would prefer generic names for new nodes. You don't need BarrierSetAssembler if these new nodes are used
only for Shenandoah. Side note, don't use #ifdef in .ad files. The check for nodes generation should be done in C2 code
during ideal graph generation.
On 11/27/18 9:54 AM, Roman Kennke wrote:
>>>> You need to check if shenandoahgc is disabled first - check
>>>> DISABLED_JVM_FEATURES list (see code for jvmci).
>>> Why? If Shenandoah is disabled, it will be on this list, and therefore
>>> not be built (see JvmFeatures.gmk).
>> Did you test with --with-jvm-variants=-shenandoahgc to make sure it is
> Test: Built the Shenandoah-patched tree with
> --with-jvm-features=-shenandoahgc. Then:
> java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC --version
> Error occurred during initialization of VM
> Option -XX:+UseShenandoahGC not supported
> Also, we regularily build minimal and zero, and those disable Shenandoah
> too, that's how we know this works reliably.
More information about the hotspot-gc-dev