EpsilonGC and throughput.

[Thomas Schatzl]

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