EpsilonGC and throughput. (original) (raw)

Thomas Schatzl thomas.schatzl at oracle.com
Wed Dec 20 12:06:37 UTC 2017

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

More information about the hotspot-gc-dev mailing list