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