EpsilonGC and throughput.

[Kirk Pepperdine]

> 
>>>> 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’re right, there is no JEP because it was made clear from discussions with the relevant parties that ValueTypes were considered to be more important at the time so the JEP process wasn’t pursued. There is an implementation in Gil’s Github account. Any implementation will require JVM support. However Gil contented that the Java code should run reasonably on JVMs that don’t have the intrinsic support.. so you can try out the libraries. There is an internal implementation in Azul’s JVM so.. it’s proven to work and have benefits.
> 
>>> 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.

According to Aleksey's benchmarks the answer appear to be yes, there is an advantage to Epsilon-GC.

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

I get that one doesn’t want to add every imaginable feature to the JVM so good question. To be honest I don’t know if 1k LOC is better than command line switches. I do know there isn’t a “one size fits all” option in this space today. There are always trade-offs. It depends on how much we trust Aleksey’s benchmarks.

— Kirk