RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector (original) (raw)

Vladimir Kozlov 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.

Thanks, Vladimir

On 11/27/18 9:54 AM, Roman Kennke wrote:

You need to check if shenandoahgc is disabled first - check DISABLEDJVMFEATURES 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 disabled? 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. Thanks, Roman

More information about the build-dev mailing list