RFC: Epsilon GC JEP

[Thomas Schatzl]

Hi Aleksey,

On Tue, 2017-07-18 at 17:41 +0200, Aleksey Shipilev wrote:
> Hi Erik,
> 
> I think we are coming to a consensus here.
> 
> Piece-wise:
> 
> On 07/18/2017 05:22 PM, Erik Helin wrote:
> > 
> > No, I don't view it that way. Having the code in the upstream
> > repository and having it exposed in binary builds are two very
> > different things to me, and comes with very different requirements
> > in terms of maintenance. If the code is in the upstream repository,
> > then it is a tool for developers working in OpenJDK and for
> > integrators building OpenJDK. We have a much easier time changing
> > such code compared to code that users have come to rely on (and
> > expect certain behavior from).
>
> Okay. I am still quite a bit puzzled why "experimental" comes with
> any notion of supportability, compatibility, testing coverage, etc. 

Every option that is exposed to the user in the product build is part
of the public API, and so must be supported similar to other options.
An experimental option is just another "official" interface to the user
as described by the CSR wiki page [1].

Just consider this: a security issue in an experimental option is just
as much a security issue in the product as any other. Since we do not
want to wait that to happen, it needs the same support and testing as
any other.

Experimental options are (at least in the GC group) more obscure
options that help you shoot yourselves into your foot performance wise
better if you fiddle too much with them :)
So the use -XX:+UseExperimentalVMOptions is more an acknowledgment for
you that you are really sure you want to do that.

They may be still required for some users for application (what we
think are) corner cases that are not (yet?) handled well automatically
by the VM. Or as alternatives for other product options that only apply
to e.g. a single collector. Or just mislabelled as such.

> I don't think most of current experimental options declared in
> globals.hpp come with that in mind. In fact, many are even marked 
> with "(Unsafe) (Unstable)"...

The VM is a very old project, from before when terms like "unit
testing", "code coverage" and related were a thing. Around 28 of those
remaining out of 1729 in globals.hpp does not sound too bad. Could be
better of course (also the actual number of switches ;)).

Also I am not sure whether they are actually unsafe and unstable any
more.

Thanks,
  Thomas

[1] https://wiki.openjdk.java.net/display/csr/ ; there is a more
detailed, likely provisional guide [2] covering options a bit more.
[2] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopers
Guide.v0.777.html#kinds_of_interfaces