EpsilonGC and throughput.

[Kirk Pepperdine]

>> 
>> 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
> tell)

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.

Kind regards,
Kirk