EpsilonGC and throughput.
kirk at kodewerk.com
Wed Dec 20 12:38:35 UTC 2017
>> 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. :)
Thank you for the platitude.
>> 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.
Just be certain that this isn’t an artifact of your benchmark.
> 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….
And that is part of my point. Many of them are simply too small relative to the size of applications today.
>> 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=
Gil Tene’s proposal on object layouts.
> 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
There are applications that have very well known memory needs and in those cases it is possible to know how big a heap needs to be in order to complete a business cycle (be it 4 hours, 8 hours, 24 hours…) without experiencing a collection cycle. Serverless is another (albeit insane) use case where epsilon looks attractive.
More information about the hotspot-gc-dev