RFR: JDK-8320336: GenShen: Reduce proactive humongous defragmentation efforts

Kelvin Nilsen kdnilsen at openjdk.org
Tue Nov 21 00:51:02 UTC 2023


On Fri, 17 Nov 2023 17:15:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Only trigger defragmentation of old-gen memory if JVM is configured to reserve a certain amount of the heap to support humongous objects.  Even when the JVM is so configured, be slightly less aggressive in triggering defragmentation of old-gen memory.

The trigger is disabled by default.  Humongous fragmentation is one of the issues that results in very high variability in performance on some workloads.  Humongous memory gets fragmented when humongous objects happen to be allocated in "the middle" of the heap instead of getting allocated at the start of the heap.  It is difficult to predict or even contrive programs that will cause this to happen.  But the typical scenario is:

1. We are operating near the "cliff's edge" so young gen consumes all of the available heap.
2. Some number of young-gen regions residing near the bottom of heap which are not necessarily contiguous are promoted in place rather than getting compacted.
3. Free regions are now scattered between these promoted-in-place heap regions, and we have no sufficiently long run of consecutive free regions to satisfy an allocation request.

With this change: We will still endeavor to defragment the old-gen memory whenever we perform a concurrent marking effort.  Concurrent marking efforts are now triggered by guaranteed interval or by growth since previous old mark.

If a service desires to keep memory defragmented because they expect frequent allocation of humongous objects, they would be wise to set -XX:ShenandoahGenerationalHumongousReserve=5 (or any value grater than 0).

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/361#issuecomment-1820037408


More information about the shenandoah-dev mailing list