RFC: Epsilon GC JEP

[Erik Helin]

Hi Aleksey,

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
   counters etc?
- 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
   remove it.

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 :)

Thanks,
Erik

* 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.
>
> Thanks,
> -Aleksey
>
> On 07/10/2017 10:14 PM, Aleksey Shipilev wrote:
>> Hi,
>>
>> I would like to solicit feedback on Epsilon GC JEP:
>>   https://bugs.openjdk.java.net/browse/JDK-8174901
>>   http://openjdk.java.net/jeps/8174901
>>
>> 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.
>>
>> Thanks,
>> -Aleksey
>>
>
>