Can JMC handle multiple YoungGarbageCollectionEvents with the same value for the gcId field?

Mon Jan 16 15:17:03 UTC 2023

Hi all,

Sorry for the HTML-email; I’ll be sprinkling with screenshots. 

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. 

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. 

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.

…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. 

If you find an actual problem in a specific visualization, just file it as a bug.

Kind regards,

Marcus

-----Original Message-----
From: jmc-dev <jmc-dev-retn at openjdk.org> On Behalf Of Erik Duveblad
Sent: Monday, 16 January 2023 12:09
To: Peter Booth <peter_booth at me.com>
Cc: jmc-dev at openjdk.org; zgc-dev at openjdk.org
Subject: Re: Can JMC handle multiple YoungGarbageCollectionEvents with the same value for the gcId field?

> On 15 Jan 2023, at 13:09, Peter Booth < <mailto:peter_booth at me.com> peter_booth at me.com> wrote:

> 

> How does this compare to the existing behavior of pre-existing collectors? 

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.

> Does it mean that IDEs, debuggers, profilers, monitoring tools might break when used with ZGC?

No, they will continue to work just fine, what I’m discussing does not affect them.

> 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?

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).

> I guess I’m trying to diplomatically ask “is this a bad smell?”

Nope, but there might be “a bad smell” in JMC :)

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.

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”.

Thanks,

Erik

> Peter

> 

> Sent from my iPhone

> 

>> On Jan 13, 2023, at 5:43 PM, Erik Duveblad < <mailto:erik.helin at oracle.com> erik.helin at oracle.com> wrote:

>> 

>> Hey all,

>> 

>> I’m looking at the JFR events that will be sent for generational ZGC [0].

>> 

>> 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.

>> 

>> The JFR events I plan for generational ZGC to send are:

>> 

>> - a “jdk.GarbageCollection” event when a “minor” or “major” garbage collection occurs

>> - a “jdk.YoungGarbageCollection” event when the young generation is collected

>> - a “jdk.OldGarbageCollection” event when the old generation is collected

>> 

>> 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:

>> 

>> - one “jdk.GarbageCollection” event with a given gcId “n"

>> - two “jdk.YoungGarbageCollection” events with the gcId field set to “n”

>> - one “jdk.OldGarbageCollection” event with the gcId field to to “n”

>> 

>> 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?

>> 

>> Thanks,

>> Erik

>> 

>> 

>> [0]:  <https://openjdk.org/jeps/8272979> https://openjdk.org/jeps/8272979

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230116/be392f4f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 227474 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230116/be392f4f/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 41292 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230116/be392f4f/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 101206 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230116/be392f4f/image003-0001.png>