JDK-8219524 : Shenandoah misreports "committed" size in MemoryMXBean
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 8-shenandoah,11-shenandoah,12,13
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- Submitted: 2019-02-21
- Updated: 2019-05-16
- Resolved: 2019-02-21
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.
To download the current JDK release, click here.
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.
To download the current JDK release, click here.
| JDK 12 | JDK 13 |
|---|---|
| 12.0.2Fixed | 13 b10Fixed  |
Related Reports
|
Relates :
|
Description
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 in JDK-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.
Comments
|