JMC parser and upcoming JFR event streaming

[Markus Gronlund]

Hello,

We have been prototyping some of the JFR event streaming capabilities that we are planning for the near future; 

Our Event Streaming JEP is still in draft state but you can take a look here:

https://bugs.openjdk.java.net/browse/JDK-8184193

Currently, our goal is to work to implement this feature for JDK13.

We have some design ideas of how we could accomplish this, and if all ideas falls out as planned, it would mean we do not have to update the file format version to introduce streaming which would be a good thing for backwards compatibility.

That said, in the streaming scenario, we will be more loose in regards to implicit ordering (established historically) of events.

For example, in the current prototype, we are elaborating on getting the bulk constant pools (event id 1) and the metadata section (event id 0) written at the start of the chunk.

Both these events have markers / pointers in the file header section that should be used by a parser to find their starting positions. Our JFR reference parsers reads these to find the correct offsets and can read up these "streaming recordings".

However, as I elaborated on getting the streaming recording loaded into JMC, it seems it only reads a small section of the file.

A conjecture is that the JMC parser only reads up to the first metadata event? The reason for this claim is that traditionally, this has been the last event in the chunk. 

This is currently only a speculation and is the reason for sending out this mail - it would be sad if we can maintain the file format but the JMC parser will not be able to parse the files just because of this issue.

Maybe you want to have the choice of incorporating this now as soon as possible, to have JMC 7 be able to read upcoming "streamed" recordings?

I have uploaded a kit with two recordings for comparison - please see:

http://cr.openjdk.java.net/~mgronlun/stream_recording_prototype/

This has used the HotMethods JMC lab, and there are two recordings per 1 minute.
One recording is the current JDK11 behavior, the other is a recording done using the current prototype "streaming system", using a flush interval every second.

Thanks
Markus