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
