-
Bug
-
Resolution: Unresolved
-
P4
-
22, 23
We recently added printing "committed" as part of VM.heap_info with JDK-8315459.
However, if we use static large pages, memory is allocated up-front and never uncommitted due toJDK-8007074.
In that case, G1 HRM goes through the motions of committing and uncommitting and counts committed regions, but at a lower level in G1PageBasedVirtualSpace, "commit" and "uncommit" are no-oped (or, more precisely, zero-filled on commit, pre-marked for future zero-fill on uncommit).
That means that G1CollectedHeap::capacity() is misleading, which makes VM.heap_info misleading as well.
We cannot just change G1CollectedHeap::capacity() since that is used for reporting as well as sizing, and in the latter case, it seems to be used as an approximation for life set size. Just setting it to max heap size would change a lot of heuristics.
Therefore we should fix places where we clearly want to report committed memory.
However, if we use static large pages, memory is allocated up-front and never uncommitted due to
In that case, G1 HRM goes through the motions of committing and uncommitting and counts committed regions, but at a lower level in G1PageBasedVirtualSpace, "commit" and "uncommit" are no-oped (or, more precisely, zero-filled on commit, pre-marked for future zero-fill on uncommit).
That means that G1CollectedHeap::capacity() is misleading, which makes VM.heap_info misleading as well.
We cannot just change G1CollectedHeap::capacity() since that is used for reporting as well as sizing, and in the latter case, it seems to be used as an approximation for life set size. Just setting it to max heap size would change a lot of heuristics.
Therefore we should fix places where we clearly want to report committed memory.