RFR: 8279124: VM does not handle SIGQUIT during initialization [v5]
Xin Liu
xliu at openjdk.java.net
Thu Jan 20 20:14:52 UTC 2022
On Thu, 20 Jan 2022 07:00:23 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>>
>> remove log_info from the signal handler.
>
> src/hotspot/os/posix/signals_posix.cpp line 600:
>
>> 598: assert(!ReduceSignalUsage, "Should not happen with -Xrs/-XX:+ReduceSignalUsage");
>> 599: signal_was_handled = true;
>> 600: }
>
> Can't we just do this as the very first thing at line 564:
>
> // If we get BREAK_SIGNAL it means we are very early in VM initialization and
> // only temporarily "handling" it to prevent the VM process getting terminated.
> if (sig == BREAK_SIGNAL) {
> assert(!ReduceSignalUsage, "Should not happen with -Xrs/-XX:+ReduceSignalUsage");
> return true;
> }
hi, David and Thomas,
I am nervous about this change. It's not complex but I don't want to break the existing java applications. Bear with me.
>From my reading, HotSpot can chain a user-custom signal handler because of libjsig.so. It's not like a linked-list chain. if the user installs a handler for a signal, libjsig just saves it. JVM_HANDLE_XXX_SIGNAL is invoked first and then the user-custom handler is called [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L635) if it isn't handled.
The reason we can hoist this logic to line 564 because we **assume** that no user application would define a handler for BREAK_SIGNAL. It doesn't work right now because os::initialize_jdk_signal_support() will overwrite the signal handler of BREAK_SIGNAL later.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7003
More information about the serviceability-dev
mailing list