harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][shutdown] How to cleanup resources safely?
Date Tue, 21 Nov 2006 10:36:47 GMT
On 11/21/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 11/20/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> 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?
>
> Evgueni, when the process is stopped, why do we need care about the
> system resource in details if they are released by the system
> automatically?

Xiao-Feng, the process is not necessarily stopped. The invocation API
defines standard way to create/destroy VM instances. Thus VM
destroying doesn't mean process termination.

>
> And the requirement below for all the native threads to comply with TM
> rule sounds like unrealistic.

It is good that you asked this question. (So you read my proposal
more-or-less carefully :-)). Let me describe this part in more
details. There are two different kind of native threads. Lets call
them user and helper threads. The difference is that user threads are
created by the application native code while helper threads are
created by VM components. There is no chance for a user thread to
interact with VM until the thread is not attached to VM. So there is
no need to care about such threads. (User should care by itself :-))
The helper threads are created by VM components and may access VM data
through inter-component interfaces. Thus we need to be sure that no
such threads are running before destroying VM-wide data.

Thanks
Evgueni
>
> Thanks,
> xiaofeng
>
> > /* 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.
> > 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.
> >
> > 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.
> >
> > Any suggestions/comments are HIGHLY welcome.
> >
> > Thanks
> > Evgueni
> >
>

Mime
View raw message