EpsilonGC and throughput.

[Aleksey Shipilev]

On 12/19/2017 07:52 PM, Sergey Kuksenko wrote:
>> Locality is something that users can control, especially when small contained applications are
>> concerned, and/or (hopefully) Valhalla and other language features that help to flatten the memory.
> Sure. Just have to note that such special tuned locality-aware application barely could use
> standard Java API, because of it is out of user control. 

You would probably be okay with small inefficiencies within the class library, if you can control
the bulk of your own data either by relying on particular classlib implementation, or winding up
your own.

> Epsilon GC is not a silver bullet,and for *practical* usage it will require more efforts than
> existing GCs to achieve benefits. I don't mind that such benefits are exist.
Well, nobody claimed Epsilon is a silver bullet. Before you can reap any of its benefits, you have
to get the footprint under control [*]. After that, you can start exploring exotic memory management
techniques, and no-op GC is one of many tools in the toolbelt there. What makes Epsilon different
from other tools is that it requires VM-side implementation -- and this is why it should be included
into JVM.

Thanks,
-Aleksey

[*] In fact, it is also called out in JEP, the other way around: fail predictably when a lot is
allocated. Over a few last months, I had a pleasant experience asserting allocation pressure
invariants with just running with Epsilon with given heap and checking if it fails. When it does, I
have the full heap-dump view of the garbage produced. This turns out to be much more convenient than
I previously anticipated.

-------------- 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/20171219/d154ff0c/signature.asc>