JDK-4324996 : (process) Runtime.exit and Runtime.halt assume process model
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: solaris_7
  • CPU: generic
  • Submitted: 2000-03-25
  • Updated: 2014-12-11
  • Resolved: 2014-12-11
Related Reports
Relates :  
VM vs. process

The JDK implementation of Runtime.halt kills the process.  That status
code returned is only meaningful to a parent process that looks at
the exit code.  There in no way to return the status code to the
main() function that called JNI_CreateJavaVM.

Multiple VMs

The fact that the JNI interface has a call JNI_GetCreatedJavaVMs
implies that there could come a day when more than one simultaneously
running VMs is supported in the same address space.  In this case,
it seems the the VMs should be protected from themselves.  Should
a System.exit() in one VM kill all of the other VMs (and the process
while it is at it?)

RTOS support

Many real-time OSes share an address space.  There may not be a way to
kill the VM and all of its threads and their resources safely like
you can kill a Unix process, short of rebooting the RTOS.

It seems like System.exit() should behave more like the application
returning from its main method.  In the latter case, we wait for
user threads to exit before shutting down the VM (not the process),
then give control back to the native code that called into the VM
using JNI.  This happens when the native code calls JNI's

A feature that would be useful for well-behaved applications (ones that
don't leave user-threads running when they call System.exit) would
be to return to the native code when the main thread calls System.exit().
For example, the call to CallStaticVoidMethod would return with
a new "VMExitException".  The native code would then call a new
JNI call GetExitCode() to get the integer status code.  Finally, it
would call DestroyJavaVM.  At this point, it is free to perform
some operation based on the status code or start a new VM, etc.

A prototype of this has been implemented in CVM, using a private
VM option.  It uses longjmp to return to the native code when the
main thread calls System.exit.  This could probably be extended to
work when System.exit is called from any user thread, not just
the main thread.  The only exception is that the application must
be well-behaved and not leave user threads running.

dean.long@Eng 2000-03-24

No requirement for multiple VMs in a single process

SUGGESTED FIX The easiest "fix" might be to add documentation for exit/halt like this: - VM shutdown includes destroying any threads created by the VM - native threads that attached themselves to the VM (including the main thread), if left running, will exit the VM by returning from their initial JNI call. - Future JNI calls will immediately return an error - Behavior beyond this is undefined and platform specific. (Solaris is free to kill the process) The platform can define its System.exit() behavior along with other platform-specific behavior like Runtime.exec(). Sound good? dean.long@Eng 2000-03-24