RFR: JDK-8282405: Make thread resource areas signal safe [v3]

Thomas Stuefe stuefe at openjdk.java.net
Thu Mar 3 05:59:04 UTC 2022


On Thu, 3 Mar 2022 02:38:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplification, copyright update
>
> src/hotspot/os/posix/signals_posix.cpp line 521:
> 
>> 519: //  an inconsistent state. We then swap back to the primary area upon leaving
>> 520: //  the signal handler.
>> 521: // Note that signal handlers can nest, and in theory we should do this on each
> 
> So what happens if you get a secondary signal whilst in the midst of trying to switch to the secondary resource area? Seems we need to ensure signals be deferred whilst this happens so that it is atomic with respect to subsequent signals.

I don't think this is necessary. 

We already block asynchronous signals (see set_signal_handler()). We explicitly allow synchronous error signals though since blocking them would just mean the process terminates right away when receiving them while blocked.

Thinking this through more, I don't see actually a way how signals could destroy the secondary RA or interrupt the switchover:
- we don't allow asynchronous signals for the time of the signal handling
- we allow error signals but that would be a programming error that should be fixed. It is preventable. If I fault when accessing the secondary resource area or trying a switch over to the secondary resource area, I should code more defensively.

This is all assuming that for ACGT the same rules hold, and whoever uses ACGT sets up the signal handler with async signals blocked. But we could just block them ourselves inside ACGT if we think this is necessary.

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

PR: https://git.openjdk.java.net/jdk/pull/7624


More information about the hotspot-runtime-dev mailing list