1

I have custom JFR event. I found that the RecodedEvent.getStartTime() is actually couple of seconds later than the time when this event was really created and committed. Then what time the getStartTime() shows?

In my case I added current time to my event and read it while jfr file parsing. But how can I get it in built-in events, like jdk.ExecutionSample?

There's a field in built-in events getLong("startTime"), but it gives strange numbers, that doesn't look like current time in millis. What is it?

Benzion
  • 25
  • 3

1 Answers1

0

By default JFR uses invariant TSC for taking timestamps (not used by System.currentMillis() or System.nanoTime()).

Invariant TSC allows JFR to have very low ovehead, but on some CPUs or in some scenarios, the clock may drift. You can use the command-line flag:

 -xx:-UseFastUnorderedTimeStamps

to get a more accurate clock, but at a higher overhead.

The time you get from event.getLong("startTime") is the raw ticks, typically only useful if you want to compare with some other system that uses the same timing mechanism.

Kire Haglin
  • 6,569
  • 22
  • 27
  • Thanks! Just to make sure I understood you correctly: RecodedEvent.getStartTime() doesn't show the exact event time, but anyway it will show correctly the order of events. Meaning if in real time event C happened after event B and B after A, then RecodedEvent_C.getStartTime() > RecodedEvent_B.getStartTime() > RecodedEvent_A.getStartTime(), correct? The order of events is very important for my application. And one more question: Is there any way to add custom fields to built-in events, like jdk.ExecutionSample. – Benzion Jul 15 '21 at 19:21
  • If the events are executing on the same core, they will come in correct order. If they are on different cores, I think there could be a slight drift, but probably very hard to prove. There is no way to add custom fields to built-in events. – Kire Haglin Jul 15 '21 at 20:26