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

Roman Kennke rkennke at redhat.com
Fri Nov 30 19:28:47 UTC 2018

Yes, Aleksey just implemented it. It will appear in round 4 in a bit.


Am 30. November 2018 20:25:35 MEZ schrieb Vladimir Kozlov <vladimir.kozlov at oracle.com>:
>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.
>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.
>>>> can be run in 'passive' mode, which doesn't involve any concurrent
>>>> (iow, it runs kindof like Parallel GC). In this mode we can
>>>> 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
>>>> up in product build), performance work quite definitely is not
>useful in
>>>> develop builds, and therefore I think it makes sense to keep them
>>>> 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
>>> 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
>> says diagnostic (!!) options must pass the TCK and/or not crash the
>> I mean, it's called diagnostic for a reason. It seems counter-useful
>> bury diagnostic flags that we would be using for diagnostics.
>>> I think the correct way to think about this is: We should pass the
>>> regardless of which features are enabled/disabled (unless the VM
>>> at start-up because the chosen combination of flags are incompatible
>>> isn't supported in the current environment, etc).
>>> CC:ing Mikael here, who might be able to shed some light on what's
>>> and not ok here.
>> Yeah, again, where is it said that diagnostic flags must even pass
>> TCK? That is totally new to me.
>> Thanks,
>> Roman

More information about the build-dev mailing list