RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
Johannes Bechberger
jbechberger at openjdk.org
Tue Jun 3 11:32:18 UTC 2025
On Tue, 3 Jun 2025 07:36:06 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> 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. ?
Regarding the acquire-release-semantics (cc @dholmes-ora): I currently use it, because it works and is fast enough. Using a weaker semantics is a good optimization, but I would abstain it for new due to time constraints.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2934793239
More information about the serviceability-dev
mailing list