RFC: Epsilon GC JEP

[Kirk Pepperdine]

Hi Micha,

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

After years of tuning these things in the wild I can honestly say that I’ve rarely seen an situation where it was a good idea for a developer to make the decision as to when GC should.. and should not run. To know when GC should run you often have to have a global view of the system and in fact, that’s what the current collectors have, a global view of the system so it’s often best to let them decide when to run…

As for Epsilon, I for one am excited to see what Aleksey cooks up. I can see a number of cases where the implementation could be useful. To be useful you will have to have tight control and a clear understanding of how you burn through memory. I seen a number of apps where this is the case and I suspect they’d benefit from the expected performance boost that I’d expect to see in the mutator threads when the interference with communicating the data structures needed to support the collector can be removed.. let the war on GC pauses continue!!!

Kind regards,
Kirk