[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: Why do we export "JVM_handle_xxx_signal"?
From:       Thomas_Stüfe <thomas.stuefe () gmail ! com>
Date:       2020-10-31 7:05:45
Message-ID: CAA-vtUzfUrCvJCvDJ-msnNShQmUsk9YhKG6byu2_jF5dwHQTxw () mail ! gmail ! com
[Download RAW message or body]

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.h=
tml

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@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=C3=BCfe 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@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/mak=
e/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=C3=BCfe 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 interna=
l
> >>> function; the signal handler is "javaSignalHandler", but that one is
> not
> >>> exported...
> >>>
> >>> Thanks, Thomas
> >>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]