EpsilonGC and throughput.

[Thomas Schatzl]

Hi,

On Tue, 2017-12-19 at 20:14 +0100, Aleksey Shipilev wrote:
> On 12/19/2017 07:52 PM, Sergey Kuksenko wrote:
> > > Locality is something that users can control, especially when
> > > small contained applications are
> > > concerned, and/or (hopefully) Valhalla and other language
> > > features that help to flatten the memory.
> > 
> > Sure. Just have to note that such special tuned locality-aware
> > application barely could use
> > standard Java API, because of it is out of user control. 
> 
> You would probably be okay with small inefficiencies within the class
> library, if you can control the bulk of your own data either by
> relying on particular classlib implementation, or winding up
> your own.

And e.g. Serial GC *by itself* has what particular dependency on
something in the OpenJDK classlib that makes that impossible? (Maybe
the java.lang.ref.reference stuff?)

> > Epsilon GC is not a silver bullet,and for *practical* usage it will
> > require more efforts than existing GCs to achieve benefits. I don't
> > mind that such benefits are exist.
> 
> Well, nobody claimed Epsilon is a silver bullet. Before you can reap
> any of its benefits, you have to get the footprint under control [*].
> After that, you can start exploring exotic memory management
> techniques, 

Can you explain to me how you can't do that with e.g. Serial GC? Is the
allocation code in Serial that much different? Actually I think it
should be almost the same. If it is not, it may be useful to clean
serial gc allocation code up instead of adding new stuff that does
exactly the same (Hint: FastTLABRefill related code will go away in
11).

It won't be called "EpsilonGC" though, and won't have an extra switch,
but benefit openjdk probably even more.

The lukewarm reception from me is mostly because I am judging on the
merits of what's in the JEP, not some future magic fairy dust that
helps every collector anyway in the future. Can you at least give some
ideas where you want to go with this, where Serial GC or any other
existing GC will prevent progress? Base "another gc" (the "exotic
memory management techniques") on it? That seems to contradict the
purpose of Epsilon GC.

To me personally the best argument that is given in the JEP seems to be
that it helps validating the GC interface - but all other GCs
implementing it also do that already to some degree (serial, parallel,
not parallelold, cms, g1, probably Shenandoah, and Z).

That just does not seem impressive.

> and no-op GC is one of many tools in the toolbelt there. What makes
> Epsilon different from other tools is that it requires VM-side
> implementation -- and this is why it should be included into JVM.

The question is: do we need a new tool that only reinvents the old ones
with minimal (I would dare to say non-real world) advantages.

> Thanks,
> -Aleksey
> 
> [*] In fact, it is also called out in JEP, the other way around: fail
> predictably when a lot is allocated. Over a few last months, I had a
> pleasant experience asserting allocation pressure
> invariants with just running with Epsilon with given heap and
> checking if it fails. When it does, I have the full heap-dump view of
> the garbage produced. This turns out to be much more convenient than
> I previously anticipated.

java "-XX:+UseSerialGC -Xmn<something> -Xms<something> -Xmx<something>
-XX:SurvivorRatio=<something> -XX:+DumpHeapAtOome" (or something like
this) myapplication

seems to give exactly the same information.

(untested; that will waste 3*4kb of memory; I can almost guarantee you
that OpenJDK static data is >8kb, so any GC will fail here. Maybe there
is even already an undocumented DieOnFirstGC development switch...)

Yes, that's a bit longer command line than "-Xmx<something>
-XX:+UseEpsilonGC -XX:+DumpHeapAtOome", but it adds exactly *zero*
maintenance overhead to the code base.

Thanks,
  Thomas