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

Martijn Verburg martijnverburg at gmail.com
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!

Cheers, Martijn

On Thu, 18 Jan 2018 at 18:19, Aleksey Shipilev <shade at redhat.com> 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