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 12:30:07 GMT
On 11/21/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 11/21/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > 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.
>
> I am not sure if this difference really makes much difference. I think
> for resource management, some coding conventions should better be
> encouraged, just like object finalizer. We can't guarantee everything
> can happen automatically and correctly.

In case of native threads we just guarantee to call registered
callback functions. Nothing more...

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