Change to crash recordings
Erik Gahlin
erik.gahlin at oracle.com
Fri Jun 19 12:57:09 UTC 2020
Hi,
I am thinking of making a change to JFR that will impact how crash recordings are written.
This could could impact the JMC parser.
When an event is registered, which typically happens when an event class is loaded, we build the binary form of the metadata event in Java and push it into the JVM in a binary form (a byte array). The reason we do this with every event registration is so we always have the latest metadata ready to write in case of a JVM crash, in which case we can’t execute Java code.
With Event Streaming, we changed how JFR works and we now flush data once every second and if an event has been registered during that period, we emit a new metadata event. This means the data in the repository is guaranteed to have proper metadata up until the last second. Previously we only wrote the metadata event at the end of a chunk, which could potentially take a very long time before it was finished (depending on the configuration). This made it more important to have an updated version of the metadata in case of a crash.
What I want to do is stop building the metadata event with every registration. This is especially problematic if you have many events you want to register.
The drawback is that a parser can’t understand how parse an event that has been registered in the last second from a crash recording. The way the JDK parser handles this is to skip the event if it is an unknown event type. In the beginning of every event the size is written, so it is very easy to skip. We also log that an unknown event type was found.
I think it would be good if the JMC parser could do the same, if it isn’t already? I looked at source code briefly and it seemed this was not the case, but I’m not sure.
Since the size of the metadata byte array grows with the number of events, the complexity becomes O(n^2), so if you want to register a large number of events, it can take minutes. With the change, the time to register and emit 50 events drops from about 350 ms to 50 ms. Since the size of the metadata byte array grows with the number of events the complexity becomes O(n^2), so if you want to register a large number of events, it can take minutes with the current implementation. See.
https://bugs.openjdk.java.net/browse/JDK-8242593
I’m not planning to bump the file format version. Crash recordings are always a best effort. There is no guarantee that they will succeed, with or without this change.
Erik
More information about the jmc-dev
mailing list