EpsilonGC and throughput.

[Kirk Pepperdine]

> 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 gage 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 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 changes the JVM that have been proposed at improving developers ability to pack memory more densely have been rejected.

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.

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.

Kind regards,
Kirk