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.

Thanks,
Roman


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


More information about the build-dev mailing list