Humongous objects vs. ShenandoahHumongousMoves

[Aleksey Shipilev]

Hi,

On 10/7/19 3:07 PM, Holger Hoffstätte wrote:
> In other words, what disadvantages would disabling this have? More and/or
> less compacted regions? Intuitively it seems to me that this would likely be
> in the noise (esp. the larger the allocated heap gets), but then I figured
> this is likely enabled for a good reason.

External heap fragmentation is a thing with humongous objects. If you churn through enough humongous
objects, you can shred your heap and another humongous allocation may fail to find an appropriate
contiguous space to allocate to, which would then fail with OOME. E.g. if every 2nd region is
reserved for a humongous object, then formally the heap is only 50% full, but it cannot allocate the
humongous object that takes 2 regions.

Concurrent GC cycle in Shenandoah does not move humongous objects, because it costs too much. The
heuristics for concurrent cycle tries to free up the contiguous blocks for allocations to feel well.
But sometimes that is not enough. This is why the last-ditch Full GC would try to compact the
humongous objects by sliding all live humongous objects to one side of the heap, thus defragmenting
it. This is what ShenandoahHumongousMoves enables.

See:
  https://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-December/004398.html

-- 
Thanks,
-Aleksey