RFR: 8291569: Consider removing JNI checks for signals SIGPIPE and SIGXFSZ [v2]

Robbin Ehn rehn at openjdk.org
Tue Jan 24 13:09:05 UTC 2023


On Mon, 23 Jan 2023 00:37:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simple enhancement to skip checking of the handlers for SIGPIPE and SIGXFSZ as we really don't care if they change, and we expect that they can.
>> 
>> The signal checking code might seem to have a redundancy as we skip these signals in two places, but the primary use of the `do_check_signal_periodically` array is to allow for only issuing one warning per signal. I could have skipped them in either place and get the same effect but it seemed inappropriate to set the array entry and not do the check; and vice-versa.
>> 
>> Testing: just basic sanity test tiers 1-3. This doesn't affect any application behaviour.
>> 
>> There are no regression tests in this specific area and it did not seem worth the effort creating one just for this.
>> 
>> Thanks.
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8291569-signals
>  - 8291569: Consider removing JNI checks for signals SIGPIPE and SIGXFSZ

I'm wondering if the user have communicated this to the VM by using the proper option, but are starting without the signal handlers yet installed.
E.g.
The user starts the VM and at later stage while doing additional class loading a dynamic library is loaded which installs SIGPIPE handler. (it can also be JVM TI agent or so which is later unloaded)
When this code no longer is relevant the user calls down to that library to shutdown, it thus removes it's signal handlers.

I have not seen that you must install your handler before CreateVM, but maybe you must?
Again a bit confused by this, maybe I understand it wrong.

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

PR: https://git.openjdk.org/jdk/pull/12062


More information about the hotspot-runtime-dev mailing list