erik.gahlin at oracle.com
Sat Feb 22 10:34:18 UTC 2020
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  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.
> On 22 Feb 2020, at 09:30, Michael Bien <mbien42 at gmail.com> wrote:
> 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,
More information about the hotspot-jfr-dev