On Tue, 3 Jun 2025 07:12:46 GMT, Johannes Bechberger <jbechber...@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 <shipi...@amazon.de> > - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp > > Co-authored-by: Aleksey Shipilëv <shipi...@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
