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

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