RFR: 8360201: JFR: Initialize JfrThreadLocal::_sampling_critical_section [v2]

[Matthias Baesken]

On Mon, 23 Jun 2025 16:31:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Initially found by UBSan. I was not able to reproduce it locally, @MBaesken would try. But the problem seems obvious: the initial value for the `bool` field is garbage. I have checked other fields in `JfrThreadLocal`, they seem fine.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8360201-jfr-init-threadlocal
>  - Fix

> Initially found by UBSan. I was not able to reproduce it locally, @MBaesken would try.

Restarted ubsan-ized builds with your patch included + tests afterwards did not show the issue on Linux aarch64 where it showed up previously.

Do we maybe have the chance to set (on some compiler toolchains) warning flags to see such uninitialized fields issues without more 'heavyweight' tools like ubsan ?
Or do we want to keep sometimes some fields uninitialized in the constructors so those warning flags would not work for us ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25938#issuecomment-2999147006