Reputation: 707
I'm working on adding custom flight recorder events to track some of our KPI's and making them exposed through flight recording dumps.
One problem that beats me though is how to flag an event as either being an "instant" or "duration" based event.
https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-guide/about.htm#JFRUH171
From my limited testing it seems like calling commit
on an event which you later reuse (say in a ThreadLocal) makes the second & upcoming calls to commit
include an end timestamp and a duration between the second commit and first.
This doesn't really fit my current use-case where I'm not interested in the timing between event creation and the commit call.
It seems to me that if you always instantiate new events and omit calling begin
you do construct an event that has no duration - but for performance reasons I'd rather avoid the overhead introduced by generating new events each time and limit heap allocations.
Upvotes: 1
Views: 244
Reputation: 7069
All events are durational in the sense they contain a field called duration. If you call commit()
without calling begin()
or end()
, the duration will be set 0. It will add one byte per event in the file and the overhead is negligible. When it comes to caching and reusing event instances, it's not supported, but it can work in some scenarios.
The recommended way is to create an object per event. In most cases, the JIT is able to eliminate the allocation if the object doesn't escape. That is, leave the method you are using the event object in.
This video describe the process for disabled events, but some of the optimization applies to enabled events as well. https://youtu.be/plYESjZ12hM?t=1126
(Escape analysis is likely to improve over time and perhaps primitive objects can be used in the future. Caching in thread locals may turn out to be an anti-pattern, especially with virtual threads coming soon)
Upvotes: 1