On 15 Jan 2023, at 13:09, Peter Booth <peter_booth@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 <erik.helin@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