Why do we export "JVM_handle_xxx_signal"?

Thomas Stüfe thomas.stuefe at gmail.com
Mon Nov 2 07:41:24 UTC 2020


(redirected this question to jdk-dev:
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-November/004887.html)

Cheers, Thomas

On Sat, Oct 31, 2020 at 8:05 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> I found old bugs from Sun about this:
>
> JDK-4864136 : JVM_handle_linux_signal is private in 1.4.2-beta
> JDK-4408646 : JVM_handle_solaris_signal must be a global function
>
> seems that the ability to call the hotspot signal handler from outside was
> a possibility for third party signal handlers to co-exist with the hotspot
> signal handler.
>
> However, nowadays we have signal chaining:
>
>
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
>
> So, I wonder whether that advice to invoke the hotspot signal handler
> manually (which I only inferred from the bug, did not find an official
> guide) from a third party user handler preceded signal chaining. Since with
> signal chaining and the libjsig, I do not see a need for manually invoking
> us:
>
> - if user installs a signal handler after we had one established, libjsig
> should be preloaded, which will take care of chaining.
> - if we install a signal handler over a user handler, we preserve it and
> chain signals to it.
>
> So. For backward compatibility we would have to preserve these exports (in
> the current form too, which is annoying). But this would really hamper
> cleanup :( I really would like to clean this up and unify some coding,
> among other things to ease porting work for us on AIX.
>
> This stuff is twenty years old though. I am hoping for some Sun
> archeological knowledge :)
>
> ..Thomas
>
>
> On Fri, Oct 30, 2020 at 1:30 PM Coleen Phillimore <
> coleen.phillimore at oracle.com> wrote:
>
>>
>> I looked through the old history and don't see any reason for this
>> naming.  My only guess is that the solaris version was exported to the
>> JDK at one time.
>>
>> It would be nice for these to have new names, and I see on the other
>> thread some of the code might be refactored?  That would be really good.
>>
>> Thanks,
>> Coleen
>>
>> On 10/30/20 2:22 AM, Thomas Stüfe wrote:
>> > Thanks for checking, Ioi. I think I'll remove the export and rename the
>> > functions.
>> >
>> > Cheers, Thomas
>> >
>> > On Fri, Oct 30, 2020 at 7:12 AM Ioi Lam <ioi.lam at oracle.com> wrote:
>> >
>> >> I have no idea, but this symbol has been exported since we moved the
>> >> HotSpot source code from SCCS to Mercurial in 2008. It's probably
>> >> vestige from the early days of Java.
>> >>
>> >>
>> >>
>> http://hg.openjdk.java.net/jdk7/modules/hotspot/annotate/9646293b9637/make/linux/makefiles/mapfile-vers-product#l244
>> >>
>> >> I checked all .so files in our JDK build and no one uses
>> >> JVM_handle_linux_signal. I think it's probably safe to hide it. We
>> >> should probably drop the JVM_ prefix, since this function is not
>> >> declared in jvm.h.
>> >>
>> >> Thanks
>> >> - Ioi
>> >>
>> >> On 10/29/20 9:02 AM, Thomas Stüfe wrote:
>> >>> Hi,
>> >>>
>> >>> Does anyone know why we explicitly export JVM_handle_bsd_signal and
>> >>> JVM_handle_linux_signal (the latter also accidentally from
>> symbols-aix)?
>> >>>
>> >>> These functions are not even the real signal handler, just an internal
>> >>> function; the signal handler is "javaSignalHandler", but that one is
>> not
>> >>> exported...
>> >>>
>> >>> Thanks, Thomas
>> >>
>>
>>


More information about the hotspot-runtime-dev mailing list