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

[Vladimir Kozlov]

Can you do simple verification of flags and exit VM gracefully with error message?

I think it should be fine. Crashing VM (unintentionally) is definitely not acceptable.

Thanks,
Vladimir

On 11/30/18 1:55 AM, Roman Kennke wrote:
>>> Hi Per,
>>>
>>> Thanks for taking time to look at this!
>>>
>>> We will take care of all the issues you mentioned.
>>>
>>> Regarding the flags, I think they are useful as they are now. Shenandoah
>>> can be run in 'passive' mode, which doesn't involve any concurrent GC
>>> (iow, it runs kindof like Parallel GC). In this mode we can selectively
>>> turn on/off different kinds of barriers. This is useful:
>>> - for debugging. if we see a crash and we suspect it's caused by a
>>> certain type of barrier, we can turn on/off those barriers to narrow down
>>> - for performance experiments: passive w/o any barriers give a good
>>> baseline against which we can measure impact of types of barriers.
>>>
>>> Debugging may or may not be useful in develop mode (some bugs only show
>>> up in product build), performance work quite definitely is not useful in
>>> develop builds, and therefore I think it makes sense to keep them as
>>> diagnostic, because that is what they are: diagnostic flags.
>>>
>>> Makes sense?
>>
>> I can see how these flags can be useful. But I think you might be in
>> violating-spec-territory here, if you're allowing users to turn on flags
>> that crash the VM. If they are safe to use in 'passive' mode, then I
>> think there should be code in shenandoahArguments.cpp that
>> rejects/corrects flag combinations that are unstable.
> 
> Let us see if we can do that.
> 
> If you think this violates the spec, then please point to the part that
> says diagnostic (!!) options must pass the TCK and/or not crash the JVM?
> I mean, it's called diagnostic for a reason. It seems counter-useful to
> bury diagnostic flags that we would be using for diagnostics.
> 
>> I think the correct way to think about this is: We should pass the TCK,
>> regardless of which features are enabled/disabled (unless the VM barfs
>> at start-up because the chosen combination of flags are incompatible or
>> isn't supported in the current environment, etc).
>>
>> CC:ing Mikael here, who might be able to shed some light on what's ok
>> and not ok here.
> 
> Yeah, again, where is it said that diagnostic flags must even pass the
> TCK? That is totally new to me.
> 
> Thanks,
> Roman
>