RFR: 8342818: Implement CPU Time Profiling for JFR

[Jaroslav Bachorik]

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Grrr ... the top level comments do not support threading, so let's quote ...

> Regarding the field samplingPeriod: @apangin mentioned in a recent meeting that naming it cpuTime and storing the thread's CPU time at the point of sampling would be better, giving us more flexibility. Not only does it convey more information, but it also allows profiler writers to merge adjacent traces if they are similar, making it possible to store the traces in a more compact format without breaking the API.

AFAIK, reading thread cpu time may incur unexpected overhead on older kernels (pre 5.1) where `clock_gettime` may not be virtualized (resulting in full syscall instead of VDSO) in a container environment. And I think we are not putting any restrictions on the kernel version where this sampler can run.

The second issue I see is that you would need to parse the events 'by thread' - eg. all events from one thread would need to be parsed sequentially in order to able to compute the delta to the previous sample from the same thread. And we need the deltas to assign them as the weight to the samples. But in real life the TLB chunks containing events from a single thread are interleaved in the recording - you can have events for T1->T2->T3->T1->T3->T2->....

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2446210928