Discussion: improve humongous objects handling for G1

[Aleksey Shipilev]

On 1/17/20 1:53 AM, Man Cao wrote:
> a. Allocation into tail regions of humongous object: JDK-8172713, JDK-8031381

Caveat: allocations near the "grandfather" humongous object would probably enjoy lots of nepotism.

> b. Commit additional virtual address space for humongous objects.

Caveat: users do like us not going over -Xmx! So this thing is better to be inside the "actual" heap.

> c. Improve the region selection heuristics (e.g., first-fit, best-fit) for
> humongous objects.

That works for solving external fragmentation (splitting the free space with a humongous alloc, for
next humongous alloc to not fit), right? Not the internal fragmentation (unused tail in the region).

> Are there any other ideas/prototypes on this front?

In Shenandoah, we found that compacting humongous regions, at least at Full GC, makes the collector
survive heavy external fragmentation, albeit at grand cost. G1 has the RFE open here:
  https://bugs.openjdk.java.net/browse/JDK-8191565

I remember J9 people telling me their GCs have "arraylets" that they spread across the regions, and
that works well right up to the point you need to do a JNI GetCritical on it.

For quite some time, I speculated that carving out the adjustable subset of regions for humongous
allocs and doing power-of-two buddy-system allocation there would be a thing to try. But, I have not
researched this thing very deeply.

-- 
Thanks,
-Aleksey