RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

Stuart Marks stuart.marks at oracle.com
Fri Feb 5 02:00:24 UTC 2016

On 2/4/16 5:05 PM, David Holmes wrote:
>> The initial task was to provide a replacement for sun.misc.Signal.
>> Sun.misc.Signal provides to Java the same set of
>> signals the VM is able to handle and exposes via the JVM_findSignal,
>> JVM_RegisterSignal, and JVM_RaiseSignal.
>> The VM carefully handles the native state and delivers a Java safe
>> notification that the signal occurred.
> And sun.misc.Signal was a private internal API not intended for public use.
> Simply elevating that API to full fledged public , supported, core API is just
> wrong IMHO.

I agree with David on this. Providing signals to Java bytecodes for JDK-internal 
use is one thing; exporting this as a public API for general use is altogether 

Just because Hotspot doesn't need a signal doesn't mean that the signal should 
be usable by any Java application. JDK internal users such as library code 
(whether native or Java) need to handle signals for internal implementation 
purposes. I see some evidence of this in Process, net, and nio. We need to make 
sure that an application's use of signals doesn't interfere with the library 


More information about the hotspot-runtime-dev mailing list