RFR: JDK-8282405: Make thread resource areas signal safe [v3]
David Holmes
dholmes at openjdk.java.net
Thu Mar 3 06:14:00 UTC 2022
On Thu, 3 Mar 2022 05:55:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> 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.
Okay that sounds reasonable - we can't get nested non-error signals.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7624
More information about the hotspot-runtime-dev
mailing list