Why do we export "JVM_handle_xxx_signal"?

David Holmes david.holmes at oracle.com
Tue Nov 3 06:01:33 UTC 2020


Responded on jdk-dev.

David

On 2/11/2020 5:41 pm, Thomas Stüfe wrote:
> (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