JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector

Martijn Verburg martijnverburg at
Thu Jan 18 10:23:57 UTC 2018

I agree with this.  Our customers (probably representing a few thousand
folks tuning GC, small sample set I know) who explicitly change GC
allocators are 99% in the “we’ve at least read the main docs as it’s
clearly an impactful change” camp, the remaining 1% get reminded quickly to
do so!


On Thu, 18 Jan 2018 at 18:19, Aleksey Shipilev <shade at> wrote:

> On 01/18/2018 11:10 AM, Erik Österlund wrote:
> > I do not feel too comfortable with this being a product flag regardless
> of the name. There is
> > existing code that assumes that for example System.gc() will actually do
> something. Similar for
> > assumptions that language features like finalizers and reference objects
> and queues will do anything
> > at all. That makes me feel uncomfortable. Do you feel comfortable with
> exposing a product flag that
> > breaks code relying on those features?
> I do feel comfortable about this, because JLS and JVMS specify that GC is
> best-effort, and therefore
> any other language and library feature that depends on GC is also
> best-effort. This allows, among
> other things: no-op GCs, reclaiming GCs that never actually do touch
> references or finalizers, GCs
> that fully ignore System.gc (remember -XX:-DisableExplicitGC that *is* a
> product option?), etc.
> I think users at large understand the choice of GC implementation matters
> in how responsive (if
> ever) the language/library features are.
> Thanks,
> -Aleksey
> --
Cheers, Martijn (Sent from Gmail Mobile)

More information about the jdk-dev mailing list