RFR: 8298175: JFR: Common timestamp for periodic events
Erik Gahlin
egahlin at openjdk.org
Wed Dec 7 05:49:03 UTC 2022
On Wed, 7 Dec 2022 05:19:15 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/internal/RequestEngine.java line 211:
>>
>>> 209: long last = lastTimeMillis;
>>> 210: // Bug 9000556 - current time millis has rather lame resolution
>>> 211: // The use of os::elapsed_counter() is deliberate here, we don't
>>
>> While you are here can you delete this comment block, or suitably modify it so that it makes sense for the code that follows. Thanks.
>
> Actually what is all this `lastTimeMillis` code for? And how does it relate to the passed in timestamp?
In Oracle JDK 8, the loop for emitting periodic events was written in native. With the rewrite that happened in JDK 9, the native logic was moved to Java, but to ensure that the mechanism worked the same, the implementation was largely kept as is. Therefore the name run_requests(...).
The timestamps in that method, for example lastTimeMillis, make sure events are emitted at the correct time, for example, one event could have the period 5s and the other 7s.
The timestamp I added is a timestamp that could be used when committing the event in native, for example:
EventJVMInformation event(UNTIMED);
event.set_jvmName(VM_Version::vm_name());
event.set_endtime(timestamp());
event.commit();
I can see if I can make the comment and naming of the variable more clear.
-------------
PR: https://git.openjdk.org/jdk/pull/11541
More information about the build-dev
mailing list