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