You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Pavel Pervov <pm...@gmail.com> on 2006/07/20 13:38:07 UTC
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more robust
Hm... I commented on dev-list on this issue already in using classlib
launcher in DRLVM.
JNI specification explicitly states that:
---------------------------------------------------------------------
After an exception has been raised, the native code must first clear the
exception before making other JNI calls. When there is a pending exception,
the only JNI functions that are safe to call are ExceptionOccurred(),
ExceptionDescribe(), and ExceptionClear().
---------------------------------------------------------------------
See [1] at the end of Exception Handling section (and the end of the page).
So, it's nice that VM won't crash if entered JNI function in exception
state, but it is obviously resposibility of native code (launcher in our
case) to check pending exceptions and process them as necessary _before_
calling into JNI.
Regards,
Pavel Pervov.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp770
On 7/20/06, Geir Magnusson Jr (JIRA) <ji...@apache.org> wrote:
>
> [ http://issues.apache.org/jira/browse/HARMONY-927?page=all ]
>
> Geir Magnusson Jr closed HARMONY-927.
> -------------------------------------
>
>
> > DRLVM's DestroyVM needs to be more robust
> > -----------------------------------------
> >
> > Key: HARMONY-927
> > URL: http://issues.apache.org/jira/browse/HARMONY-927
> > Project: Harmony
> > Issue Type: Bug
> > Components: DRLVM
> > Reporter: Andrey Chernyshev
> > Assigned To: Geir Magnusson Jr
> > Attachments: destroy_vm.patch
> >
> >
> > drlvm should handle the fact that an exception already exists on
> entering DestroyJavaVM, and clear it before trying to resolve the VMStart
> class.
> > Here is a small patch that adds a simple check into the shutdown method.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more robust
Posted by Pavel Pervov <pm...@gmail.com>.
On 7/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
> patch welcome ;)
>
> geir
Working on it. :)
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more
robust
Posted by Geir Magnusson Jr <ge...@pobox.com>.
patch welcome ;)
geir
Pavel Pervov wrote:
> Hm... I commented on dev-list on this issue already in using classlib
> launcher in DRLVM.
>
> JNI specification explicitly states that:
> ---------------------------------------------------------------------
> After an exception has been raised, the native code must first clear the
> exception before making other JNI calls. When there is a pending exception,
> the only JNI functions that are safe to call are ExceptionOccurred(),
> ExceptionDescribe(), and ExceptionClear().
> ---------------------------------------------------------------------
> See [1] at the end of Exception Handling section (and the end of the page).
>
> So, it's nice that VM won't crash if entered JNI function in exception
> state, but it is obviously resposibility of native code (launcher in our
> case) to check pending exceptions and process them as necessary _before_
> calling into JNI.
>
> Regards,
> Pavel Pervov.
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp770
>
> On 7/20/06, Geir Magnusson Jr (JIRA) <ji...@apache.org> wrote:
>>
>> [ http://issues.apache.org/jira/browse/HARMONY-927?page=all ]
>>
>> Geir Magnusson Jr closed HARMONY-927.
>> -------------------------------------
>>
>>
>> > DRLVM's DestroyVM needs to be more robust
>> > -----------------------------------------
>> >
>> > Key: HARMONY-927
>> > URL: http://issues.apache.org/jira/browse/HARMONY-927
>> > Project: Harmony
>> > Issue Type: Bug
>> > Components: DRLVM
>> > Reporter: Andrey Chernyshev
>> > Assigned To: Geir Magnusson Jr
>> > Attachments: destroy_vm.patch
>> >
>> >
>> > drlvm should handle the fact that an exception already exists on
>> entering DestroyJavaVM, and clear it before trying to resolve the VMStart
>> class.
>> > Here is a small patch that adds a simple check into the shutdown
>> method.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more robust
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <ol...@googlemail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more
robust
Posted by Oliver Deakin <ol...@googlemail.com>.
Sorry for the delay - once again swamped with backlog...
Comments inline:
Pavel Pervov wrote:
> On 7/20/06, Oliver Deakin <ol...@googlemail.com> 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.
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more robust
Posted by Pavel Pervov <pm...@gmail.com>.
On 7/20/06, Oliver Deakin <ol...@googlemail.com> 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... :)
This is a sort of compatibility with user code though rather than following
some spec.
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.
> 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.
WBR,
Pavel Pervov.
Intel Middleware Products Division.
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more
robust
Posted by Oliver Deakin <ol...@googlemail.com>.
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.
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 - however it does
make the exit more likely to complete successfully, so I think it is a
change worth
making. Is there any reason against making the change?
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?
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/%3c44BB6895.2070809@googlemail.com%3e
Pavel Pervov wrote:
> Hm... I commented on dev-list on this issue already in using classlib
> launcher in DRLVM.
>
> JNI specification explicitly states that:
> ---------------------------------------------------------------------
> After an exception has been raised, the native code must first clear the
> exception before making other JNI calls. When there is a pending
> exception,
> the only JNI functions that are safe to call are ExceptionOccurred(),
> ExceptionDescribe(), and ExceptionClear().
> ---------------------------------------------------------------------
> See [1] at the end of Exception Handling section (and the end of the
> page).
>
> So, it's nice that VM won't crash if entered JNI function in exception
> state, but it is obviously resposibility of native code (launcher in our
> case) to check pending exceptions and process them as necessary _before_
> calling into JNI.
>
> Regards,
> Pavel Pervov.
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp770
>
> On 7/20/06, Geir Magnusson Jr (JIRA) <ji...@apache.org> wrote:
>>
>> [ http://issues.apache.org/jira/browse/HARMONY-927?page=all ]
>>
>> Geir Magnusson Jr closed HARMONY-927.
>> -------------------------------------
>>
>>
>> > DRLVM's DestroyVM needs to be more robust
>> > -----------------------------------------
>> >
>> > Key: HARMONY-927
>> > URL: http://issues.apache.org/jira/browse/HARMONY-927
>> > Project: Harmony
>> > Issue Type: Bug
>> > Components: DRLVM
>> > Reporter: Andrey Chernyshev
>> > Assigned To: Geir Magnusson Jr
>> > Attachments: destroy_vm.patch
>> >
>> >
>> > drlvm should handle the fact that an exception already exists on
>> entering DestroyJavaVM, and clear it before trying to resolve the
>> VMStart
>> class.
>> > Here is a small patch that adds a simple check into the shutdown
>> method.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>
>>
>>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org