<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<pre>Hi Erik,
The proposal you outline below is reasonable. The API was designed to
allow any number of memory pools managed by a memory manager that
can represent different phases of a garbage collector or other
resource manager to expose various metrics. How G1 exposes these
monitoring metrics is implementation specific.
More comments inlined below.
</pre>
<div class="moz-cite-prefix">
<pre wrap="">On 1/25/18, 5:27 AM, "Erik Helin" <a class="moz-txt-link-rfc2396E" href="mailto:erik.helin@oracle.com"><erik.helin@oracle.com></a> wrote:
</pre>
</div>
<blockquote type="cite"
cite="mid:878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com">
<pre wrap="">
Hi Paul,
thanks for your interest in this area and for your patch! The
GarbageCollectorMXBean and MemoryPoolMXBean support for G1 is in need of
some updates, so thanks for working on this.
Looking at your patch, I'm not sure that this is the direction we want
to go in. I discussed this a bit with Thomas and Stefan J, and our
current line of thinking is the following:
- Memory pools (MemoryMXBean):
- "G1 Eden Regions"
- "G1 Survivor Regions"
- "G1 Old Regions"
- "G1 Humongous Regions"
- "G1 Archive Regions" (if CDS and/or AppCDS is used)
</pre>
</blockquote>
<br>
<pre>Can you describe more about G1 archive regions? Is it an immutable region
that no object will be added or removed?
</pre>
<blockquote type="cite"
cite="mid:878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com">
<pre wrap="">
`init` for these pools would be 0, `used` would be total size of the
"live" objects in the used regions of that type, `committed` the total
size of the used regions of that that type and `max` would be
MaxHeapSize. Note that "live" here means live from the GCs point of
view, i.e. an object might be dead in an old region but the GC will
consider that object live until a concurrent cycle has marked through
the heap and deemed it dead.</pre>
</blockquote>
<br>
<pre>As specified in MemoryPoolMXBean spec, for MemoryPoolMXBean::getUsage of
a garbage-collected memory pool, the amount of used memory includes the
memory occupied by all objects in the pool including both reachable
and unreachable objects.
OTOH, getCollectionUsage returns the memory usage after JVM most recently
expended effort in recycling unused objects in this memory pool. It
would depend on what a GC cycle is defined for G1 and at what phase
G1 can record the "collection usage" with low overhead. Definitely
the API does not request G1 to perform any GC-like action and "collection
usage" reports how much memory is used at most recent GC cycle after some
memory has been reclaimed.
</pre>
<blockquote type="cite"
cite="mid:878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com">
<pre wrap="">
- Collectors (GarbageCollectorMXBean):
- "G1 Young Collector" with the pools
- "G1 Eden Regions"
- "G1 Survivor Regions"
- "G1 Humongous Regions" (due to early reclamation)
- "G1 Mixed Collector" with the pools
- "G1 Eden Regions"
- "G1 Survivor Regions"
- "G1 Old Regions"
- "G1 Humongous Regions" (due to early reclamation)
- "G1 Full Collector" with the pools
- "G1 Eden Regions"
- "G1 Survivor Regions"
- "G1 Old Regions"
- "G1 Humongous Regions" (can collect empty humongous regions)
- "G1 Concurrent Cycle" with the pools
- "G1 Old Regions" (can collect empty old regions)
- "G1 Humongous Regions" (can collect empty humongous regions)
Note that with this design, the
GarbageCollectorMXBean::getCollectionTime() method for "G1 Concurrent
Cycle" would be the wall clock time from start of the first initial mark
to end of the last cleanup (also including the time of any eventual
young collection during the concurrent cycle). So
GarbageCollectorMXBean::getCollectionTime() would be a mix of concurrent
and STW time for the GarbageCollectorMXBean with name "G1 Concurrent Cycle".
</pre>
</blockquote>
<br>
<pre>GarbageCollectorMXBean API was defined prior to G1. It's a future
enhancement to investigate how to represent the concurrent garbage
collection metrics for better monitoring purpose. Do you have any
thought for monitoring of G1 GC metrics besides memory usage?
</pre>
<blockquote type="cite"
cite="mid:878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com">
<pre wrap="">
Also note that the MemoryPoolMXBean with name "G1 Archive Regions" will
not be attached to any GarbageCollectorMXBean, since those regions will
never be collected.
What do you think about this design, would it work for your use case?
If we want to go ahead with this design, then I think we might have to
file a CSR. David (who is the HotSpot CSR representative), do we have to
file a CSR for changing the names of MemoryPoolMXBeans and
GarbageCollectorMXBeans?
</pre>
</blockquote>
<br>
<pre>The names are not a supported interface but I'm not surprised applications
may depend on the names. CSR as well as a release note to document
this change is reasonable.
Mandy
</pre>
<br>
</body>
</html>