<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I created JDK-8196362 to look into whether it makes sense to
provide some categorization to differentiate eden space vs the heap
space for long-lived objects. <br>
<br>
W.r.t. to JDK-8195115, I have to defer to GC team to comment on the
mixed collection update. If they are okay, I have no objection to
implement a short-term fix and do the proper G1 memory pools as a
separate patch. <br>
<br>
Mandy<br>
<br>
<div class="moz-cite-prefix">On 1/29/18 1:02 PM, Hohensee, Paul
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E7D008FD-DEC5-4A06-9FD4-6905D2DB4FAA@amazon.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New",serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1">
<p class="MsoNormal">We don’t use getType, and you guessed
correctly: we use the memory pool name as an indicator of the
specific characteristics of a memory pool, in particular eden.<o:p></o:p></p>
<p class="MsoNormal"><o:p>Â </o:p></p>
<p class="MsoNormal">What we want is an indication of long term
heap occupancy. We calculate it using CollectionUsage for
non-eden heap memory pools, regardless of collector. We don’t
use JMX notification, rather we periodically poll
CollectionUsage for memory pools with names that contain
“Oldâ€, “Tenuredâ€, or “Survivorâ€. We get the memory pools from
the GarbageCollectorMXBeans (we don’t care what the collector
names are). For the named memory pools, we sum
CollectionUsage.used and divide by the sum of
CollectionUsage.max to get a long term heap occupancy
percentage. We don’t want to include eden because it’s really
just an allocation buffer and not part of the storage for
long-lived objects. I suppose we could use a negative test
instead by using all memory pools with names that don’t
include “Edenâ€.<o:p></o:p></p>
<p class="MsoNormal"><o:p>Â </o:p></p>
<p class="MsoNormal">The bug is that the “G1 Old Gen†memory
pool isn’t being updated when the “G1 Young Generationâ€
collector runs a mixed collection. As far as JMX is concerned,
that collector only knows about eden and the survivor space.
The patch adds the old gen to the memory pools it knows about
and has mixed collections update the old gen’s
CollectionUsage.<o:p></o:p></p>
<p class="MsoNormal"><o:p>Â </o:p></p>
<p class="MsoNormal">I managed to get a submit repo run to
succeed last week and it found a problem. I’ve uploaded a new
webrev that fixes the failure of the jtreg test
TestMemoryMXBeansAndPoolsPresence.java due to the young gen
collector being expected to know only about eden and the
survivor space.<o:p></o:p></p>
<p class="MsoNormal"><o:p>Â </o:p></p>
<p class="MsoNormal"><a
href="http://cr.openjdk.java.net/%7Ephh/8195115/webrev.hs.01/"
moz-do-not-send="true">http://cr.openjdk.java.net/~phh/8195115/webrev.hs.01/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p>Â </o:p></p>
<p class="MsoNormal">Waiting on the submit repo to come back
with a result on it.<o:p></o:p></p>
<p class="MsoNormal"><o:p>Â </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"><o:p>Â </o:p></p>
<p class="MsoNormal">Paul<o:p></o:p></p>
<p class="MsoNormal"><o:p>Â </o:p></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:12.0pt;color:black">From: </span></b><span
style="font-size:12.0pt;color:black">mandy chung
<a class="moz-txt-link-rfc2396E" href="mailto:mandy.chung@oracle.com"><mandy.chung@oracle.com></a><br>
<b>Organization: </b>Oracle Corporation<br>
<b>Date: </b>Monday, January 29, 2018 at 10:52 AM<br>
<b>To: </b>"Hohensee, Paul" <a class="moz-txt-link-rfc2396E" href="mailto:hohensee@amazon.com"><hohensee@amazon.com></a>,
Erik Helin <a class="moz-txt-link-rfc2396E" href="mailto:erik.helin@oracle.com"><erik.helin@oracle.com></a>, David Holmes
<a class="moz-txt-link-rfc2396E" href="mailto:david.holmes@oracle.com"><david.holmes@oracle.com></a><br>
<b>Cc: </b><a class="moz-txt-link-rfc2396E" href="mailto:serviceability-dev@openjdk.java.net">"serviceability-dev@openjdk.java.net"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:serviceability-dev@openjdk.java.net"><serviceability-dev@openjdk.java.net></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:hotspot-gc-dev@openjdk.java.net">"hotspot-gc-dev@openjdk.java.net"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:hotspot-gc-dev@openjdk.java.net"><hotspot-gc-dev@openjdk.java.net></a><br>
<b>Subject: </b>Re: RFR (S): 8195115: G1 Old Gen
MemoryPool CollectionUsage.used values don't reflect mixed
GC results<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p>Â </o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>Â </o:p></p>
<div>
<p class="MsoNormal">On 1/29/18 10:35 AM, mandy chung wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">Thanks for
the reply Paul.  Try to understand a little more on the
specific from gc-specific memory pool you depend on.<o:p></o:p></p>
<div>
<p class="MsoNormal">On 1/29/18 8:27 AM, Hohensee, Paul
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">A name change would affect Amazon’s
heap monitoring, and thus I expect it would affect other
users as well.<o:p></o:p></p>
<p class="MsoNormal">Â <o:p></o:p></p>
<p class="MsoNormal">As long as there are gc-specific memory
pools, we’re going to need to be able to identify them,
and right now that’s done via name.
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
MemoryPoolMXBean::getType returns "heap" memory type for
GC-specific memory pools. Are you using this method? Do
you use the name to build in specific characteristic of a
memory pool (e.g. eden vs old gen)?<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">All the mxbeans are identified by name,
so that’s a general design principle. The only way I can
think of to get rid of name dependency would be to figure
out what abstract metrics users want to monitor and
implement them for all collectors. HeapUsage
(instantaneous occupancy) is one, CollectionUsage
(long-lived occupancy) is another, both of these for the
entire heap, not just particular memory pools.
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
The sum of HeapUsage and CollectionUsage of all heap memory
pools was expected to give an incorrect approximation for
the entire heap usage. Are you seeing issue/bug with the
sum result?
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
typo: s/an incorrect approximation/an approximation.<br>
<br>
Mandy<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Mandy<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">That said, imo there will always be a
demand for the ability to get collector and memory pool
specific details, so I don’t see a way to get around
providing named entities.<o:p></o:p></p>
<p class="MsoNormal">Â <o:p></o:p></p>
<p class="MsoNormal">Paul<o:p></o:p></p>
<p class="MsoNormal">Â <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:12.0pt;color:black">From: </span></b><span
style="font-size:12.0pt;color:black">mandy chung
<a href="mailto:mandy.chung@oracle.com"
moz-do-not-send="true"><mandy.chung@oracle.com></a><br>
<b>Organization: </b>Oracle Corporation<br>
<b>Date: </b>Friday, January 26, 2018 at 2:38 PM<br>
<b>To: </b>"Hohensee, Paul" <a
href="mailto:hohensee@amazon.com"
moz-do-not-send="true"><hohensee@amazon.com></a>,
Erik Helin
<a href="mailto:erik.helin@oracle.com"
moz-do-not-send="true"><erik.helin@oracle.com></a>,
David Holmes <a href="mailto:david.holmes@oracle.com"
moz-do-not-send="true">
<david.holmes@oracle.com></a><br>
<b>Cc: </b><a
href="mailto:serviceability-dev@openjdk.java.net"
moz-do-not-send="true">"serviceability-dev@openjdk.java.net"</a>
<a href="mailto:serviceability-dev@openjdk.java.net"
moz-do-not-send="true"><serviceability-dev@openjdk.java.net></a>,
<a href="mailto:hotspot-gc-dev@openjdk.java.net"
moz-do-not-send="true">"hotspot-gc-dev@openjdk.java.net"</a>
<a href="mailto:hotspot-gc-dev@openjdk.java.net"
moz-do-not-send="true"><hotspot-gc-dev@openjdk.java.net></a><br>
<b>Subject: </b>Re: RFR (S): 8195115: G1 Old Gen
MemoryPool CollectionUsage.used values don't reflect
mixed GC results</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Â <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Â <o:p></o:p></p>
<div>
<p class="MsoNormal">On 1/25/18 1:04 PM, Hohensee, Paul
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
> The JMX API spec doesn’t specify what the memory pool
or garbage > collector names are, but the current names
are de-facto part of the > API, so if we change the
existing ones, imo a CSR should be filed.<o:p></o:p></p>
<pre>The names are implementation details but I can see how an application<o:p></o:p></pre>
<pre>might be impacted if they depend on it. CSR approval is not strictly<o:p></o:p></pre>
<pre>necessary while I think filing one to document the change would be <o:p></o:p></pre>
<pre>good.<o:p></o:p></pre>
<p class="MsoNormal">Â <o:p></o:p></p>
<pre>Does the name change impact any application you know of? I'm trying to<o:p></o:p></pre>
<pre>understand if any improvement to API is needed so that applications <o:p></o:p></pre>
<pre>don't need to depend on the names.<o:p></o:p></pre>
<p class="MsoNormal"><br>
Mandy<br>
<br>
<br>
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p>Â </o:p></p>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
</div>
</blockquote>
<br>
</body>
</html>