JDK-8369036 : Parallel: JDK-8348278: Trim InitialRAMPercentage caused a performance regression in Footprint3-SwingSet
Type:Bug
Component:hotspot
Sub-Component:gc
Affected Version:26
Priority:P2
Status:Closed
Resolution:Other
Submitted:2025-10-02
Updated:2025-12-16
Resolved:2025-12-16
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
We can observe a 13% regression in Footprint3-SwingSet using Parallel GC on Linux x64.
Have isolated the regression to JDK-8348278.
Comments
I'm closing this after JDK-8373023 has been integrated, changing InitialRAMPercentage to 0. We will follow a similar (really the same regression but with new numbers) in JDK-8373712.
16-12-2025
The footprint regression (as measured by `status_VmHWM`) is very likely caused by whether a GC cycle has run for this bm, because when GC threads start to run (inside a GC cycle/pause), they can page-in much memory for GC bookkeeping data.
Obviously, whether a GC cycle is triggered or not is affected by initial-heap-size, and there are two recent changes that affect initial-heap-size JDK-8369346 and JDK-8369346.
The running machine has 502G.
[0.003s][info][gc,init] Memory: 502G
## InitialRAMPercentage = 1.5 (before JDK-8369346)
[0.004s][info][gc,init] Heap Initial Capacity: 2G
No GC triggered.
## InitialRAMPercentage = 0.2 (after JDK-8369346)
[0.003s][info][gc,init] Heap Initial Capacity: 264M
One GC cycle triggered.
## MaxRam lifted (after JDK-8369346)
[0.003s][info][gc,init] Heap Initial Capacity: 1030M
No GC triggered.
After JDK-8369346, the footprint is roughly back to what is observed at the very beginning.