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

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