RFC: Epsilon GC JEP

[Thomas Schatzl]

Hi,

On Thu, 2017-12-14 at 16:29 -0500, Micha Berger wrote:
> On Thu, Dec 14, 2017 at 09:42:53PM +0100, Roman Kennke wrote:
> > Am 14.12.2017 um 21:18 schrieb Aleksey Shipilev:
> > > On 12/14/2017 01:15 AM, mberger wrote:
> > > > I think Epsilon supporting System.gc() /
> > > > Runtime.getRuntime().gc() would be very useful. And if the
> > > > behavior isn't wanted, well there is always
> > > > -XX:+DisableExplicitGC.
> > > And that will do what? System.gc() requests are ignored by
> > > Epsilon, because there is nothing to do.
> > I believe he wanted to say that it'd be useful if it *did*
> > something
> > (i.e. collect garbage). I presume the idea is to never do GC,
> > except
> > when explicitely requested.
> 
> Yes, I was saying that in contrast to doing no GC, I would find it
> useful
> to have a GC system that only collects on demand.
> 
> For example, a server that collects garbage when the number of
> connected clients goes to zero. It could tolerate a small amount of
> object accumulation, possibly stay up indefinitely. (Depending upon
> usage patterns.) And yet it would only delay a socket connection if
> there is a new client vary shortly after.
> 

I strongly recommend comparing to serial/parallel gc with a huge eden
and small survivor/small old gen is likely to have the same performance
with the following advantages:

- you can do your system.gc() trickery
- it does not crash and burn immediately when your allocation area
(eden) is out
- previous compaction of any data generated during startup is probably
going to outweigh the performance loss (i.e. do a system.gc() like you
would e.g. do for benchmarking something after startup)

The drawback is that you loose some heap space, which can be close to
zero if you size your generations correctly, and some memory due to
side data structures - they are minimal particularly in Serial.

As for throughput loss of the barriers, literature [1] indicates
something like 0.9%+-0.8%, i.e. extremely small overhead that could be
easily gained back elsewhere.

This does not take into account throughput gains due to locality
improvements which can be very significant compared to Epsilon because
of compaction. At the cost of some probably very small pauses, but
taanstafl.

Thanks,
  Thomas

[1] Xi Yang, Stephen M. Blackburn, Daniel Frampton, and Antony L.
Hosking. 2012. Barriers reconsidered, friendlier still!. SIGPLAN Not.
47, 11 (June 2012), 37-48. DOI=http://dx.doi.org/10.1145/2426642.225900
4