Hello
I've just noticed this discussion and thought I may give some observation
because I spent some time working on drlvm initialization and JNI code.
1. Constructions like
if (jenv->ExceptionOccurred()) {...}
are an overhead if you just want to know if there is an exception pending. The
function ExceptionOccurred returns a jobject allocating a local object handle
and possibly creating all the stack trace in case of lazy exceptions. This
all is not needed if this object is not required. JNI 1.2 provides a simpler
jboolean function ExceptionCheck which just returns JNI_TRUE if there is a
state of exception and nothing else. Also inside of drlvm exceptions
interface provide a direct (as opposed to indirect JNI calls) function
exn_raised().
2. I think it is Ok to make DestroyVM to work in case of pending exception.
After all it should just eliminate this VM with all its exceptions and all
its stuff all together :)
Whethere or not VM shutdown succeeds in case of OOME it not a question about
drlvm, it may fail in other VMs as well if there is no heap memory left. So
if it fails, there is just no other way but to abort VM shutdown and return
to the caller with no exception since there is no working VM left after this
call.
Generally though, if launcher gets OOME before calling DestroyVM it means that
some stack frames of the main program were unwound and some objects may be
freed from the heap so unless main program did something nasty like creating
objects with finalizers that create other objects, some memory should be
available for VM shutdown.
On Thursday 27 July 2006 18:55 Oliver Deakin wrote:
> Sorry for the delay - once again swamped with backlog...
> Comments inline:
>
> Pavel Pervov wrote:
> > On 7/20/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
> >> I agree Pavel - it should be fixed in the launcher. But, as I said in
> >> [1], we should
> >> give some consideration to the fact that the RI and IBM vms exit
> >> gracefully
> >> under the same circumstances, and that perhaps we should also try to
> >> fix this in the drlvm to match their behaviour.
> >
> > Not sure how do you know about RI... :)
>
> The JNI invocation API is standard across jvms, so it requires no internal
> knowledge for me to write a generic launcher app that causes an exception
> to be thrown and then calls DestroyJavaVM.
>
> > This is a sort of compatibility with user code though rather than
> > following
> > some spec.
>
> I don't see it as compatability, but more user friendliness. If this small
> change makes the VM appear more robust to the user, then all the better!
>
> > I started to think of ways simply calling ExceptionClear wouldnt result
> >
> >> in a clean exit from drlvm. An OutOfMemoryError followed by
> >> DestroyJavaVM
> >> would probably still result in a failure in VMStart, so just calling
> >> ExceptionClear might not be enough to guarantee clean exit
> >
> > It is then the problem of VMStart to be able to work in strict memory (or
> > even out-of-memory) conditions. :) Let's not mix things.
>
> ok, perhaps this is a different issue - I was really just commenting
> that the fix
> submitted with this JIRA will not entirely get rid of shutdown failures
> triggered by launching code in VMStart after an exception.
>
> >> Thinking about this makes me wonder how drlvm will exit cleanly when
> >> there is an
> >> OutOfMemoryError when running it from the drlvm launcher. If the heap
> >> is full, surely trying to run shutdown code in VMStart is dangerous
> >> anyway?
> >
> > VMStart.shutdown() will most probably throw OutOfMemoryError itself.
> > But I'm
> > not sure how it may be dangerous.
>
> I do not know a great deal about what happens during VMStart.shutdown(),
> but the following question came into my mind while thinking about this
> issue:
> If VMStart.shutdown() throws an OOM itself, then doesn't that imply that
> some of the shutdown sequence will not be completed, meaning that whatever
> should have been cleaned up or freed during the rest of the shutdown isn't
> getting done?
>
> Perhaps I'm giving to much importance to the VMStart.shutdown() method and
> it doesn't matter if it is exited prematurely - but I thought it was
> worthwhile asking
> this question.
>
> Regards,
> Oliver
>
> > WBR,
> > Pavel Pervov.
> > Intel Middleware Products Division.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
