RFC: Epsilon GC JEP
erik.helin at oracle.com
Tue Jul 18 10:09:47 UTC 2017
first of all, thanks for trying this out and starting a discussion.
Regarding the JEP, I have a few questions/comments:
- the JEP specifies "last-drop performance improvements" as a
motivation. However, I think you also know that taking a pause and
compacting a heap that is mostly filled with garbage most likely
results in higher throughput*. So are you thinking in terms of pauses
here when you say performance?
- why do you think Epsilon GC is a good baseline? IMHO, no barriers is
not the perfect baseline, since it is just a theoretical exercise.
Just cranking up the heap and using Serial is more realistic
baseline, but even using that as a baseline is questionable.
- the JEP specifies this as an experimental feature, meaning that you
intend non-JVM developers to be able to run this. Have you considered
the cost of supporting this option? You say "New jtreg tests under
hotspot/gc/epsilon would be enough to assert correctness". For which
platforms? How often should these tests be run, every night? Whenever
we want to do large changes, like updating logging, tracing, etc,
will we have to take Epsilon GC into account? Will there be
serviceability support for Epsilon GC, like jstat, MXBeans, perf
- You quote "The experience, however, tells that many players in the
Java ecosystem already did this exercise with expunging GC from their
custom-built JVMs". So it seems that those users that want something
like Epsilon GC are fine with building OpenJDK themselves? Having
-XX:+UseEpsilonGC as a developer flag is much different compared to
exposing it (and supporting, even if in experimental mode) to users.
Please recall that even removing/changing an experimental flag
requires a CSR request and careful motivation as why you want to
I guess most of my question can be summarized as: this seems like it
perhaps could be useful tool for JVM GC developers, why do you want to
expose the flag to non-JVM developers (given all the
work/support/maintenance that comes with that)?
It is _great_ that you are experimenting and trying out new ideas in the
VM, please continue doing that! Please don't interpret my
questions/comments as to grumpy, this is just my experience from
maintaining 5-6 different GC algorithms for more than five years that is
speaking. There is _always_ a maintenance cost :)
* almost always. There will of course be scenarios where the throughput
could be higher without compacting.
On 07/18/2017 10:55 AM, Aleksey Shipilev wrote:
> No comments? I'll ask OpenJDK Lead to move this JEP to Candidate soon then.
> On 07/10/2017 10:14 PM, Aleksey Shipilev wrote:
>> I would like to solicit feedback on Epsilon GC JEP:
>> The JEP text should be pretty self-contained, but we can certainly add more
>> points after the discussion happens.
>> For the last few months, there were quite a few instances where Epsilon proved a
>> good vehicle to do GC performance research, especially on object locality and
>> code generation fronts. I think it also serves as the trivial target for
>> Erik's/Roman's GC interface work.
>> The implementation and tests are there in the Sandbox, for those who are curious.
More information about the hotspot-gc-dev