RFC: Epsilon GC JEP

[Aleksey Shipilev]

(I have read the rest)

Okay, you have convinced me, maintainers do not want to have it exposed as
experimental option. Would you be willing to accept it as develop then?

Other random ramblings:

On 07/18/2017 03:34 PM, Thomas Schatzl wrote:
> Running it daily, on X platforms on Y OSes for Z releases adds up
> quickly. Could run something else instead. And there is always
> something else to run on these machines, trust me. :)

Right. Well, I have recently authored a few changes [1,2] that made Shenandoah
GC tests run around 20% faster in fastdebug. I suppose some of that improvement
is applicable to other GCs too. My question is, can I please have 1 minute of
that machine time per build back as payment? :D

[1] http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f922d99ce776
[2] http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/9fe3d41b0e51

> The question is, by how much. So academics (and I am not trying to hit
> on academics here, you brought them up ;)) that write a paper on GC but
> never need to rebuild the VM (including the JDK here) because they
> don't do any changes would be inconvenienced.
> 
> Let me ask, how many do you expect these to be? From my understanding there
> seems to be a very manageable yearly total GC paper output at the usual
> conferences. Not sure how putting Epsilon GC in product would improve that.

"Build it and they will come" works here. "develop" is seen as unstable and
untouchable by most.

> As for the amount of inconvenience, I think the users that already need
> to recompile for their changes are not very much inconvenienced. I.e.
> changing a single "develop" to "product" seems to be a very small
> effort.

Okay, we can do this downstream.

> Aren't ultra-power-users able to rebuild the VM? What is their cost vs.
> the effort spent into making their applications garbage-free or
> implementing the necessary workarounds to be able to use that gc
> (mentioned load-balancer trickery etc)?

I am pretty sure they would be much, much, much happier to download the
Oracle/RedHat/Azul's binary build and run with it in production, thus
capitalizing on all the testing those companies did for their JDK binaries.
Native compilers and native toolchains are the bottomless sources of bugs too,
right?


Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170718/8108b960/signature.asc>