jdk.Checkpoint
Michael Bien
mbien42 at gmail.com
Sat Feb 22 23:36:43 UTC 2020
Hi Erik,
thank you for the detailed response
On 22.02.20 11:34, Erik Gahlin wrote:
> 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).
Interesting. I had the feeling that it might have something to do with
synchronization for event streaming. I suppose the API is only allowed
to consume events up until the most recent checkpoint, then it waits for
the next and so on.
>
> Do you see a problem with the additional 8 MB of data, or are you just curious?
I was curious for the most part. With the default profile i probably
wouldn't have even noticed it. But i came from the perspective of
evaluating if JFR could be used as logging replacement. The good news is
that it is static uptime footprint and it doesn't increase with load
which is great. But on the other hand you could put a lot of log lines
into ~8MB daily.
Maybe it would be possible to consider making the flush/checkpoint
interval configurable for use cases where the realtime nature of event
streaming is less important. Or maybe this is the wrong approach and I
should only view the JFR records as log buffer and use streaming to
extract what is needed for compact storage.
>
> Our thinking was that it would be harmless.
mostly harmless :)
>
> Thanks
> Erik
thanks again,
michael
> [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
>>
More information about the hotspot-jfr-dev
mailing list