EpsilonGC and throughput.

[Thomas Schatzl]

Hi,

On Wed, 2017-12-20 at 12:19 +0100, Kirk Pepperdine wrote:
> > On Dec 19, 2017, at 8:14 PM, Aleksey Shipilev <shade at redhat.com>
> > 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.
> > 
> > > 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, 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.
> 
> That a bench with Epsilon will not complete to me is completely
> unsurprising. It is my opinion that there are (niche) classes of
> applications that are not well served by the current set of
> benchmarks used to gauge JVM performance and I don’t see how one can
> gauge Epsilon performance based on these benchmarks. In fact, IME,
> most of the benchmarks don’t push the JVM in ways that are close to
> what I consistently see in production environments. That and these 

Then please help providing ones which we VM devs can use to improve the
VM. :)

> environments are changing while the benchmarks have remained
> relatively static. The talk about cache locality while interesting
> I’m not sure it is relevant or a good predictor of performance given
> that current design practice discourage good cache line densities and

It is all about caches nowadays :) E.g. in our tests with ZGC we are
seeing surprisingly good throughput numbers due to caching effects.
I.e. ones that seem to contradict what I remember of literature.

I guess Aleksey is all over putting ZGC through their benchmarks right
now, maybe he can tell us more.

SPECjvm2008 is maybe also a very conservative indicator for caching
impact due to compaction: it's live data set for many of its tests is
really small, and the actively accessed amount of memory probably even
smaller. Some of them even maybe fit completely into today's L3 caches
of current (high-end) machines....

I mean, if G1 with its notoriously huge barrier (which can be improved
btw, if you want to work on this just ask) and rather bad (really
bloated, i.e. in some cases extremely cache unfriendly) remembered set
can already "win" of some of these benchmarks... (again, just ask).

> changes the JVM that have been proposed at improving developers
> ability to pack memory more densely have been rejected.

Not sure about this. E.g. value types I think are actively developed?
Please elaborate. Maybe you are just talking to the wrong people=

> The way to scale is to do the same (or more) with less. Epsilon does
> less and encouraged application developers to do less for the same
> workloads. Whenever this happens I’ve rarely seen a performance
> regression but instead seen a couple performance improve by a few
> orders of magnitude.

You mean improve caching/memory usage? I agree :)

> While Aleksey initially proposed Epsilon for experimental test
> purposes I’d already considered a number of cases where live
> applications would benefit from being able use (no-)GC. So, I agree
> with Aleksey, this option should be included or at least be made to
> be easily plug-able into OpenJDK.
> 

You mentioned this twice already without going into detail. Could you
please elaborate about this, particularly compared to a for such cases
properly configured Serial/Parallel GC?
(Note that Epsilon GC *also* needs at least some heap size
configuratoin; so unless adding -Xmn/-Xms is too much work compared to
significant changes to your application to fit this paradigm, please
tell)

Thanks,
  Thomas