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

Thomas Stüfe thomas.stuefe at gmail.com
Sat Mar 18 07:47:38 UTC 2017

Hi David,

I had a look a the changes and think them fine so far.

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.
only documents linking against the libjsig.so from the directory of the
embedded VM.

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?

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.

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 :)

On Fri, Mar 17, 2017 at 10:58 PM, David Holmes <david.holmes at oracle.com>

> 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
>> 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

More information about the hotspot-runtime-dev mailing list