Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4324996

(process) Runtime.exit and Runtime.halt assume process model

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: 1.4.0
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • CPU:
      generic
    • OS:
      solaris_7

      Description

      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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                dlong Dean Long
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: