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

David Holmes david.holmes at oracle.com
Mon Dec 3 00:38:12 UTC 2018


On 30/11/2018 8:40 pm, Per Liden wrote:
> Hi,
> 
> 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.

That cannot be true in a strict sense ref:

./share/runtime/globals.hpp:  diagnostic(ccstr, AbortVMOnException, NULL,

which would obviously fail the TCK.

However I think there is a distinction between a flag that causes the VM 
to abruptly terminate versus a flag that allows the VM to run in a 
manner that violates the spec.

David
-----

> 
> But let's have someone who knows more about the rules around that weight 
> in on this.
> 
> cheers,
> Per



More information about the build-dev mailing list