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
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
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
