RFC: Epsilon GC JEP

[Aleksey Shipilev]

On 12/14/2017 10:29 PM, 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 understand the use case.

Epsilon is not doing any runtime work, except for handling the allocations. Any GC work would need
to cooperate with runtime (scanning roots, doing weakrefs, class unloading, etc), it would take
native memory to track object mark words / references during the collection, etc. Then you would
want _parallel_ Full GC, which complicates implementation. In the end, you will arrive to another
(badly implemented) GC with no apparent gain. So, if you need GC, it is easier to configure other
implementations to resort to GC only in dire circumstances.

For example, Shenandoah with "passive" heuristics (which is a diagnostic mode, but might be
interesting anyway) would disable concurrent phases, and rely only on Full GC to reclaim memory. In
return, it would not have any barriers enabled (including inter-generational ones that
serial/parallel would enable being unconditionally generational), and would not do GC until the very
last moment or until user asks for it with System.gc(). This will waste some memory for forwarding
pointers, but you have already accepted waste with Epsilon. This would get close enough to Epsilon
with Full GC implemented.

TL;DR: Epsilon is deliberately a no-op GC, and it does not tread on other collectors when "real" GC
reclamation is needed. Use other GCs if you need memory reclamation.

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20171215/839b4281/signature.asc>