Hi, this is a great improvement! :)

Does this mean that a correct handling of CPU and WALL events is something like this:
CPU: jdk.ExecutionSamples events and filter out all events except from STATE_DEFAULT
WALL: profiler.WallClockSample events -> cummulate over samples field

There is no need for any kind of mapping between jdk.ExecutionSamples and profiler.WallClockSample, am I right?

Thanks, Petr

Does it make sense to record other events than STATE_DEFAULT into jdk.ExecutionSample ?

@petrbouda The meaning of jdk.ExecutionSample remains unchanged: it may represent both CPU and Wall clock events depending on state field as before. profiler.WallClockSample is an additional way to represent multiple wall clock samples as one event.

JfrReader transparently converts both event types to ExecutionSample.

I agree it would be clearer to leave jdk.ExecutionSample only for CPU events and profiler.WallClockSample for Wall clock events. I will probably change this in the future.

Hi Andrei, thank you for your answer. I've already looked into JfrReader to understand your parsing logic.
Preparing support in Jeffrey :) ... this is a cool feature, thanks a lot!

It was actually trivial: I modified profiler to always emit different events for CPU vs. Wall clock samples.
Now wall clock engine writes profiler.WallClockSample only, and CPU engine writes jdk.ExecutionSample with STATE_DEFAULT.

Note: if nobatch option is specified, both CPU and Wall clock profiler emit jdk.ExecutionSample as before.

Cool! It makes recordings much smaller 🙂