-
Bug
-
Resolution: Fixed
-
P3
-
8-shenandoah, 11-shenandoah, 12, 13
-
b10
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8219667 | 12.0.2 | Aleksey Shipilev | P3 | Resolved | Fixed | b01 |
This is reported by Ruslan Synytsky. He noticed that Shenandoah misreports "committed" size via MemoryMXBean. On his test case, it looks like this:
[27.908s][info][gc] Uncommitted 1040M. Heap: 2048M reserved, 5M committed, 4M used
11:04:43 -> Init: 32M Used: 4M Committed: 2048M Max: 2048M
The first line is report by Shenandoah itself. The second line is the data from MXBean. So, while only 5M is actually committed, MXBean reports 2048M as committed.
This is caused in jdk12+ by clash with memory usage accounting redone inJDK-8207200. Shenandoah always reports capacity() as max_capacity(), because it "resizes" the heap by committing regions as needed. This makes default implementation in CollectedHeap::memory_usage() believe all memory is committed by Shenandoah at all times.
[27.908s][info][gc] Uncommitted 1040M. Heap: 2048M reserved, 5M committed, 4M used
11:04:43 -> Init: 32M Used: 4M Committed: 2048M Max: 2048M
The first line is report by Shenandoah itself. The second line is the data from MXBean. So, while only 5M is actually committed, MXBean reports 2048M as committed.
This is caused in jdk12+ by clash with memory usage accounting redone in
- backported by
-
JDK-8219667 Shenandoah misreports "committed" size in MemoryMXBean
-
- Resolved
-
- relates to
-
JDK-8207200 Committed > max memory usage when getting MemoryUsage
-
- Resolved
-