<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=en-CH link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoPlainText><span lang=EN-US>Hi all,<br><br>Sorry for the HTML-email; I’ll be sprinkling with screenshots. <br><br>As far as I can remember, JMC does not make any such assumptions. We usually try to pick all events related to a @relational attribute when we visualize them. <br><br>For example, in the GC page, any and all phases with a matching gcId to the selected GC will be showed in the phases table. <br></span><span lang=en-CH><img width=2112 height=1080 style='width:22.0in;height:11.25in' id="Picture_x0020_1" src="cid:image001.png@01D929B7.1D5CB830"></span><span lang=EN-US><br><br>That said, more generally JMC does not specifically constrain associations to be made only for @relational fields/attributes. It is enough for the id and type to be the same to be considered a match.<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><br><img width=753 height=505 style='width:7.8437in;height:5.2604in' id="Picture_x0020_2" src="cid:image002.png@01D929C5.F8845AE0"><br><br></span><span lang=EN-US>…though using the feature will, of course, be even more useful for fields that are @relational (since the annotation suggest that there is a relation across event types, and it is therefore likely that a match can be found across multiple types). Here is an example of matching on gcId being 11, and showing the matching entries in the event browser. <br><br></span><span lang=en-CH><img width=1260 height=673 style='width:13.125in;height:7.0104in' id="Picture_x0020_3" src="cid:image003.png@01D929C5.F8845AE0"></span><span lang=en-CH><br><br></span><span lang=EN-US>If you find an actual problem in a specific visualization, just file it as a bug.<br><br>Kind regards,<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-US>Marcus</span><span lang=en-CH><br><br><o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-US style='mso-fareast-language:#2000'>-----Original Message-----<br>From: jmc-dev <jmc-dev-retn@openjdk.org> On Behalf Of Erik Duveblad<br>Sent: Monday, 16 January 2023 12:09<br>To: Peter Booth <peter_booth@me.com><br>Cc: jmc-dev@openjdk.org; zgc-dev@openjdk.org<br>Subject: Re: Can JMC handle multiple YoungGarbageCollectionEvents with the same value for the gcId field?</span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>> On 15 Jan 2023, at 13:09, Peter Booth <<a href="mailto:peter_booth@me.com"><span style='color:windowtext;text-decoration:none'>peter_booth@me.com</span></a>> wrote:<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>> How does this compare to the existing behavior of pre-existing collectors? <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>Not at all actually, any collector in HotSpot is free to implement a garbage collection as one or more attempts to collect one or more generations. There are concepts such as “last ditch collections” and has been concepts such as “scavenge before remark”, this is nothing an application observes.<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>> Does it mean that IDEs, debuggers, profilers, monitoring tools might break when used with ZGC?<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>No, they will continue to work just fine, what I’m discussing does not affect them.<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>> For the scenario where there two minor GCs does this we have two events that aren’t equal yet can’t be distinguished or “looked up?” Are these event objects conceptually immutable value objects or are they owned by the first GC event object?<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>The JFR event system doesn’t really work like that. Each event is just data and has a unique id per event. We use the field “gcId” in a number of events to logically group multiple events as part of one logical garbage collection (this is a human interpretation of the field “gcId”, to JFR it is (almost) just a field).<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>> I guess I’m trying to diplomatically ask “is this a bad smell?”<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>Nope, but there might be “a bad smell” in JMC :)<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>I don’t know the JMC source code, but if there is code that for example has a `HashMap<Integer, Event> youngCollectionEventPerGC` where the code (conceptually) does `youngCollectionEventPerGC.put(event.gcId(), event)`, then such code will now be buggy (since generational ZGC might send *two* YoungGarbageCollection events with the same value for the “gcId” field). The property that there is only one YoungGarbageCollection JFR event per GC isn’t something that HotSpot has ever guaranteed, but it is also the way things have worked until now, so I can see why code like the one I just showed could have found its way into JMC.<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>Which is the exact reason I’m asking here if anyone is aware if such an assumption have found their way into the JMC source code? I don’t expect anyone to go through JMC’s entire source code, I was more on the lookout for anyone potentially recalling “oh, yes, we actually made this exact assumption for view X, Y and Z”.<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>Thanks,<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>Erik<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p><p class=MsoPlainText><span lang=en-CH>> Peter<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>> Sent from my iPhone<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> On Jan 13, 2023, at 5:43 PM, Erik Duveblad <<a href="mailto:erik.helin@oracle.com"><span style='color:windowtext;text-decoration:none'>erik.helin@oracle.com</span></a>> wrote:<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> Hey all,<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> I’m looking at the JFR events that will be sent for generational ZGC [0].<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> With generational ZGC there are broadly speaking two kinds of garbage collections (“minor” and “major”) and each garbage collection can collect one or more generations, zero or more times. More concretely, a minor garbage collection will collect the young generation once and a major garbage collection will collect the young generation _one or two times_ and the old generation once.<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> The JFR events I plan for generational ZGC to send are:<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> - a “jdk.GarbageCollection” event when a “minor” or “major” garbage collection occurs<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> - a “jdk.YoungGarbageCollection” event when the young generation is collected<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> - a “jdk.OldGarbageCollection” event when the old generation is collected<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> Combining the above means that there is a new situation: when a major garbage collection occurs that collects the young generation *two* times and the old generation once, then the following events will be sent:<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> - one “jdk.GarbageCollection” event with a given gcId “n"<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> - two “jdk.YoungGarbageCollection” events with the gcId field set to “n”<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> - one “jdk.OldGarbageCollection” event with the gcId field to to “n”<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> This would be the first time a HotSpot garbage collector sends multiple (two in this case) “jdk.YoungGarbageCollection” events with the same value for the gcId field. So I wanted to check with you all if JMC makes any assumptions or relies upon the fact that up until now all “jdk.YoungGarbageCollection” events have a unique value for the “gcId” field?<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> Thanks,<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> Erik<o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> <o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH>>> [0]: <a href="https://openjdk.org/jeps/8272979"><span style='color:windowtext;text-decoration:none'>https://openjdk.org/jeps/8272979</span></a><o:p></o:p></span></p><p class=MsoPlainText><span lang=en-CH><o:p> </o:p></span></p></div></body></html>