Thanks for discussing this, it's important... Evgueni Brevnov wrote: > Hi All, > > I'd like to share with you my findings regarding current DRLVM > shutdown procedure (not in too many details) and discuss further steps > to improve it. > > /* General words about shutdown */ > > Here is a snip from the j.l.Runtime.addShutdownHook() spec: > > "The Java virtual machine shuts down in response to two kinds of events: > 1) The program exits normally, when the last non-daemon thread exits > or when the exit (equivalently, System.exit) method is invoked, or > 2) The virtual machine is terminated in response to a user interrupt, > such as typing ^C, or a system-wide event, such as user logoff or > system shutdown." > > Except these 2 events there is one more player on the scene. It is > DestroyJavaVM defined by invocation API.User calls DestroyJavaVM to > request reclamation of all resources owned by the VM. > > As it was discussed earlier (and I think agreed) the System.exit() > should terminate entire process the VM is running in right after it > executed shutdown hooks and finalizes. At least RI does so. Thus I > would like to look closer at the case when the last non-daemon thread > exits and the VM is requested to cleanup resources through > DestroyJavaVM. When DestroyJavaVM is called it waits until current > thread is the last non-daemon thread before cleaning up all resources > owned by the VM. It is important to note it is still possible daemon > java and native threads are running inside the VM even if there is no > running non-daemon threads. These running threads may still be using > VM-wide data (generally located in Global_Env). Thus before cleaning > resources up we need to stop these threads somehow. Unfortunately, we > can't just kill threads. We need to release all resources (system > locks, heap/stack memory, open files/connections, etc) owed by each > thread. So the problem I'd like to discuss and solve: How to stop > running threads in a safe manner? > > /* Current DRLVM implementation */ > > Currently, the DRLVM isn't able to stop running threads in a safe way. > Thus it just doesn't clean resources up if there are running threads > after all non-daemon threads exits. > > /* How to stop threads safely. Proposal. */ > > I propose to consider native and java threads separately. Lets start > with native threads. > > Native threads: It seems there is not much we can do to stop arbitrary > native thread and release resources owed by it. I don't consider > global resource management as a possible solution here :-). Thus there > are two requirements for native threads to ensure safe VM shutdown: > > a) Any native thread must be created by TM or attached to TM. So TM is > aware about all running native threads.
I don't believe you can mandate 'must' here, it is unenforceable. > b) Native thread provides a callback which is called to request thread > shutdown. It's the native thread responsibility to clean its resources > upon shutdown request. Agreed, that is a sensible solution. Any threads that know they need clean-up work on shutdown may register to be informed when the shutdown is about to occur. I expect we will want describe the state of the VM at that point, and put restrictions on what threads can do in that callback function. > Java threads: We have much more control other java threads. Namely it > is possible to unwind the stack in a safe way. When the VM needs to > stop a java thread it asynchronously raises an exception to that > thread. The VM ensures that the exception will not be caught by any > java exception handler (ala j.l.ThreadDeath exception). This guarantee > full and safe java stack unwinding. If there is no user native frames > on the stack (JNI calls) then thread exits normally otherwise the > control is returned to the user's code with an exception raised. It is > the user's responsibility to handle exception properly and clean up > all resources allocated by native code. Sounds good. > Any suggestions/comments are HIGHLY welcome. I think this can be quite a generic application resource lifecycle API, and the API should be put into a library that the classlib natives can share. In that case the classlib code can register clean-up functions for open system resources too. Sounds like a VMI extension to me. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
