jdk.Checkpoint

[Erik Gahlin]

Hi Michael,

jdk.CheckPoint is an event users can't consume or manipulate. It is hard-wired into the file format and only visible to the ‘jfr’ tool (for debugging purposes).

The event contains mapping to constants. For example, if an event has a stack trace, only the ID for the stack trace is written. Later in the file, a check point event is written that maps the ID to the stack trace This is to reduces the size of the recording file.

With JDK 14, we introduced Event Streaming [1] which allow clients to attach to the disk repository of a running JVM (in-process and out-of-process) and continuously stream events. This feature is always on and data is flushed once every second. With each flush a check point event is written. These events adds up over a day (86 400 seconds).

Do you see a problem with the additional 8 MB of data, or are you just curious?

Our thinking was that it would be harmless.

Thanks
Erik

[1] https://openjdk.java.net/jeps/349


> On 22 Feb 2020, at 09:30, Michael Bien <mbien42 at gmail.com> wrote:
> 
> Hello,
> 
> i was testing JFR with custom events using a mostly empty custom.jfc file and noticed a large amount of jdk.CheckPoint events in the resulting repository and dump files (both count and size wise) after a few hours of uptime (using JDK 14). I tried to explicitly disable the event in the profile config but it didn't help. It seems to be around 8MB of jdk.CheckPoint events per day for a mostly idling app server.
> 
> Accessing the event with the jfr commandline tool or API didn't work either and I couldn't find any other information on it.
> 
> What is it for? Some implementation detail needed for the file structure?
> 
> best regards,
> 
> michael
>