Integrated: 8295125: os::signal should be os specific
David Holmes
dholmes at openjdk.org
Mon Oct 31 06:00:16 UTC 2022
On Thu, 20 Oct 2022 05:59:33 GMT, David Holmes <dholmes at openjdk.org> wrote:
> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
>
> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
> - signal
> - user_handler
> - raise
> The first two were reworked and placed into PosixSignals and os::win32.
> There was no need for a specific XX::raise API as os::raise simply called ::raise.
>
> On the Posix side we had the basic signal handler installation code in two places:
>
> 1. Inline in set_signal_handler and used by nearly all the VM signals
> 2. In os::signal which was used by three different "clients"
> - VM error handler for updating crash handler
> - VM for installing SIG_BREAK handler
> - JDK via JVM_RegisterSignal
>
> This was refactored so that we have:
>
> 1. PosixSignals::install_sigaction_signal_handler
> - used by the VM only
> - set_signal_handler
> - VM error handler for updating crash handler
> - VM for installing SIG_BREAK handler
>
> 2. PosixSignals::install_generic_signal_handler
> - used by JDK via JVM_RegisterSignal
>
> The sigaction handlers were all consistently defined as per the posix definition:
> void func(int signo, siginfo_t *info, void *context);
>
>
> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
>
> Thanks.
This pull request has now been integrated.
Changeset: 9b9be88b
Author: David Holmes <dholmes at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/9b9be88bcaa35c89b6915ff0c251e5a04b10b330
Stats: 165 lines in 9 files changed: 81 ins; 33 del; 51 mod
8295125: os::signal should be os specific
Reviewed-by: jsjolen, kbarrett
-------------
PR: https://git.openjdk.org/jdk/pull/10780
More information about the hotspot-runtime-dev
mailing list