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

[Roman Kennke]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181130/8d814886/signature.asc>