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

[Vladimir Kozlov]

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
>