harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm][shutdown] How to cleanup resources safely?
Date Tue, 21 Nov 2006 13:05:37 GMT
2006/11/21, Evgueni Brevnov <evgueni.brevnov@gmail.com>:
> 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.
>
> <SNIP>
> 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.
> </SNIP>
Ah, it's me who misunderstood the initial wording; now this is quite clear.
Thanks!

>
> > Other paragraphs look super, well-though. Great job!
> Glad to hear that.
>
> Thanks
> Evgueni
> >
> > >
> > > Any suggestions/comments are HIGHLY welcome.
> > >
> > > Thanks
> > > Evgueni
> > >
> >
>

Mime
View raw message