harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm][shutdown] How to cleanup resources safely?
Date Tue, 21 Nov 2006 12:04:29 GMT
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.



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message