RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]

[David Holmes]

On Tue, 3 Jun 2025 07:12:46 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipilëv <shipilev at amazon.de>
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipilëv <shipilev at amazon.de>
>  - Small fixes

> Regarding [#25302 (comment)](https://github.com/openjdk/jdk/pull/25302#discussion_r2119984783)
> 
> ```
> raw_thread == nullptr
> ```
> 
> This seems to happen rarely on (abrupt) shutdowns. I attached an hs_err file: [hs_err_pid1688961.log](https://github.com/user-attachments/files/20563594/hs_err_pid1688961.log)

That is interesting. The signal appears to be being handled on an unattached thread during shutdown, and there is no stack left to show any VM involvement. Possibly we need to block the signal as part of thread termination, before we clear the current thread. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2933916367