EpsilonGC and throughput. (original) (raw)

Thomas Schatzl thomas.schatzl at oracle.com
Wed Dec 20 14:23:01 UTC 2017

Hi,

On Wed, 2017-12-20 at 13:38 +0100, Kirk Pepperdine wrote:

> > > 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.

Assuming that with these

> > 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.

I am not seeing any work on that, not even a JEP. So maybe Gil and you are not pushing it enough. Otoh it may just take some time, as value types did.

> 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.

Unfortunately that answer again does not answer my question - the particular part about "... particularly compared to a for such cases properly configured Serial/Parallel GC" is important here.

I mean, we want to add 1k LOC that to a large degree I think copies Serial GC (allocation) code, and want to argue that this outweighs using a few command line switches (see the other email).

Thanks, Thomas

More information about the hotspot-gc-dev mailing list