RFR (10) (S) 8175817: Clean up Solaris signal code: SIGUSR2, SIGasync, SIGJVM1/2

[David Holmes]

Hi Thomas,

On 18/03/2017 5:47 PM, Thomas Stüfe wrote:
> Hi David,
>
> I had a look a the changes and think them fine so far.

Thanks for looking at this.

> The stricter libjsig version check means that applications will break
> now which did embed the libjsig into their applications by grabbing it
> from the VM and shipping it separately, and where the libjslig.so is now
> outdated. But I guess this is a remote scenario, and probably also
> illegal.
> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/signal-chaining.html
> only documents linking against the libjsig.so from the directory of the
> embedded VM.

Right. There was never any expectation that anyone would link libjsig 
into their application. But the point is moot anyway as the version 
number has never changed since its introduction in 1.4.1.

> So we now require the build machine to provide SIGJVM1/2. That is fine
> and a good cleanup. Do I understand this right, were we now to run on
> older OSes which do not know SIGJVM1, we would probably silently use the
> SIGRT.. range, right, because 40 falls into this? Or is that no issue,
> are there runtime checks preventing us from starting on older releases?

We've required a Solaris 10 minimum build and runtime machine for quite 
a while now. I don't know what would happen if you tried to run current 
binaries on Solaris 9. By the time 10 is release the minimum platforms 
may have moved on even further.

> Apart from this, I wonder if we could at some time unite this SR_..
> coding. Handling for suspend/resume looks similar on all the other posix
> platforms. But that ties in with whether signal handling in general
> could be unified for all posix platforms.

Certainly possible, but pretty low priority.

> Kind Regards, Thomas
>
> p.s. I like the fact that solaris has a SIGJVM1/2, I did not know that.
> The things one can do if one owns the OS :)

Indeed :)

Thank again for looking at this and giving it such scrutiny.

David

>
> On Fri, Mar 17, 2017 at 10:58 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Can I get a Review please.
>
>     Thanks,
>     David
>
>
>     On 16/03/2017 11:00 PM, David Holmes wrote:
>
>         Bug: https://bugs.openjdk.java.net/browse/JDK-8175817
>         <https://bugs.openjdk.java.net/browse/JDK-8175817>
>
>         webrev: http://cr.openjdk.java.net/~dholmes/8175817/webrev/
>         <http://cr.openjdk.java.net/~dholmes/8175817/webrev/>
>
>         On Solaris SIGasync represents what we call the "SR signal" on other
>         platforms (the event-based suspend/resume signal), and it is
>         hardwired
>         to SIGJVM2 (a dedicated JVM signal on Solaris 10+).
>
>         As this signal is hard-wired and has not been user-definable at
>         runtime
>         for a very long time, we can do away with the SIGasync field and its
>         setter and getter, and simply define ASYNC_SIGNAL as SIGJVM2 (not
>         SIGUSR2 as the code currently suggests!). Once this is a build time
>         constant it simplifies some other code.
>
>         We can also stop trying to account for SIGJVM1/2 not existing as
>         they
>         must exist on the supported Solaris platforms.
>
>         We can also stop trying to deal with an older libjsig (the logic for
>         which has a bug anyway: used <= instead of < in the version check).
>
>         Overall just a bit of simplification and cleanup. No functional
>         changes.
>
>         Testing: JPRT
>
>         Thanks,
>         David
>
>