JDK-8332531 : Parallel: Parellel GC resizes heap too aggressive
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-05-20
  • Updated: 2025-04-23
Related Reports
Relates :  
Relates :  
Relates :  
Description
Our application is transaction based. Upon finishing a transaction, it is likely to release quite amount of memory. If a GC happens, it likely shrinks heap. Once a new transaction starts to execute, heap starts to expand again. Shrinking and expanding heap are expensive and unnecessary, also impacts on pause time (I would like to measure in next a few days)
 
While we can now workaround it by setting -Xms = -Xmx after JDK-8332418, I believe we should still fix it.

Comments
Won't be able to get to it in the near future, unassigned myself.
08-07-2024

@ayang Yes, lazy-uncommit is the direction I am heading to. Another option is to use timer to record how long the free space is available for uncommit, similar to ZUncommitDelay and ShenandoahUncommitDelay. I won't be able to get to it in a next few weeks, please feel free to take over. Thanks.
23-05-2024

I believe one simple way to add lazy-uncommit to Parallel can be to record the used-bytes in old-gen for the past certain number of GCs and use the max value for `size_t live = ParallelScavengeHeap::heap()->old_gen()->used_in_bytes();` in the calculation of `PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes`.
23-05-2024

And Shenandoah has `ShenandoahUncommitDelay`
22-05-2024

Seems that Parallel is the only one that doesn't support "lazy" shrink -- e.g. Serial supports `ShrinkHeapInSteps` and ZGC uses `ZUncommitDelay`...
22-05-2024

Changing `AdaptiveSizeDecrementScaleFactor` value does not seem to change resizing frequency.
21-05-2024

According to its name, `AdaptiveSizeDecrementScaleFactor` seems related.
20-05-2024