RFR (round 3), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector
per.liden at oracle.com
Fri Nov 30 10:40:13 UTC 2018
On 11/30/18 10: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.
I'm not really the right person to speak authoritatively about this.
However, from what I understand it doesn't matter what kind of flag it
is. If a user can enable it in a production/shipped build I think it
must pass the TCK.
But let's have someone who knows more about the rules around that weight
in on this.
More information about the hotspot-dev