RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code
Kim Barrett
kbarrett at openjdk.org
Wed Oct 15 00:58:07 UTC 2025
On Tue, 14 Oct 2025 20:20:18 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> src/hotspot/os/posix/signals_posix.cpp line 172:
>>
>>> 170: static OSXSemaphore* sr_semaphore;
>>> 171: #else
>>> 172: static PosixSemaphore* sr_semaphore;
>>
>> I don't think consistency with the other semaphore is a great reason for
>> avoiding the use of `DeferredStatic` here. Indeed, I would prefer that
>> `DeferredStatic` be used for both semaphores.
>>
>> I think the only change from what's already being proposed here to make
>> `sr_semaphore` be `DeferredStatic` is the declaration and the initialization.
>>
>> The changes needed for `sig_semaphore` to be `DeferredStatic` are pretty
>> small. Change the declaration and initialization, and os::signal_notify needs
>> to be adjusted. The last I think actually makes the code clearer and more
>> consistent.
>>
>>
>> void os::signal_notify(int sig) {
>> - if (sig_semaphore != nullptr) {
>> + if (!ReduceSignalUsage) {
>> AtomicAccess::inc(&pending_signals[sig]);
>> sig_semaphore->signal();
>> - } else {
>> - // Signal thread is not created with ReduceSignalUsage and jdk_misc_signal_init
>> - // initialization isn't called.
>> - assert(ReduceSignalUsage, "signal semaphore should be created");
>> }
>> }
>>
>>
>> That would change a too-early signal to a crash in a product build, except our
>> signal handlers are installed after the semaphores are initialized.
>
> Thanks for taking a look @kimbarrett . I expected someone would say "why not switch both to DeferredStatic?" and I don't have an issue doing that (missing init checks notwithstanding), but it wasn't my immediate goto because I don't see `DeferredStatic as really being any superior to declaring a pointer instead (which is how we do lazy initialization in 99.9% of the VM).
DeferredStatic avoids the memory allocation for initialization, and removes a
memory dereference when using.
We use pointers at least in part because the technology on which
DeferredStatic is based requires C++11 (which we've not been using for all
that long). And it took a while for someone to get sufficiently annoyed with
the pointer idiom to try to do better.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2430851278
More information about the hotspot-runtime-dev
mailing list