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:10:52 GMT
On 11/21/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> [snip]
> > 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.
> This part looks a bit contradictory: on the one hand, "VM ensures the
> exception will not be caugth", and on the other "control is returned
> to user's code with the exception raised". I presume you made a slip
> on the last and actually meant we can unwind safely and free
> stack-related VM resources; but then we should postpone shutdown
> hooks/finalizers until no other Java threads running including
> daemons?

Alexey, I really appreciate your interest to this topic.
Unfortunately, I can't fully understand what you are asking about..
:-( The idea is we are able to unwind java and VM native stack with
cleaning resources on the way. Unfortunately we can't do the same with
user native frames. So we propagate an exception up to the most recent
user frame if any. The user code should be ready to process the
exception and release allocated resources if any. All this is
consistent with the JNI spec. Here is the snip from the spec regarding
asynchronous exceptions.

Asynchronous Exceptions
In cases of multiple threads, threads other than the current thread
may post an asynchronous exception. An asynchronous exception does not
immediately affect the execution of the native code in the current
thread, until:

the native code calls one of the JNI functions that could raise
synchronous exceptions, or
the native code uses ExceptionOccurred() to explicitly check for
synchronous and asynchronous exceptions.
Note that only those JNI function that could potentially raise
synchronous exceptions check for asynchronous exceptions.

Native methods should insert ExceptionOccurred()checks in necessary
places (such as in a tight loop without other exception checks) to
ensure that the current thread responds to asynchronous exceptions in
a reasonable amount of time.

> Other paragraphs look super, well-though. Great job!
Glad to hear that.

> >
> > Any suggestions/comments are HIGHLY welcome.
> >
> > Thanks
> > Evgueni
> >

View raw message