You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Etienne Gagnon <eg...@sablevm.org> on 2006/04/04 21:14:05 UTC
[vmi] JNI spec interpretation?
Hi,
I have started playing with the launcher and SableVM. I have a little
fun trying to figure out how to debug the thing using DDD. The execv
trick was a nasty one to get over... Anyway, now that it works, I am
facing a JNI specification interpretation problem.
It seems that the launcher assumes that it is OK to call
(*env)->ExceptionDescribe() even when there is no pending exception.
My reading of the JNI spec is different. The spec says:
"... This function has the side effect of clearing *the* pending
exception..."
This contrasts with ExceptionClear which says:
"...Clears *any* pending exception... If no exception..."
Therefore, I always assumed that the necessarily was a pending
exception. One cannot talk about *the* pending exception, if there is
not necessarily one. Otherwise, the spec would have said: ...clearing
any pending exception...
What do others think? Should I file a bug against the launcher, i.e:
native-src/shared/launcher/main.c line 1006
?
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [vmi] JNI spec interpretation?
Posted by Archie Cobbs <ar...@dellroad.org>.
Tim Ellison wrote:
> So what should a VM do if somebody calls ExceptionDescribe() and there
> is no pending exception?
>
> (a) blow up
> (b) silently ignore it, since there is nothing to describe
> (c) print out something along the lines of 'no exception'
FWIW, here is what JCHEVM will do:
If assertions enabled: assertion failure
If assertions disabled: core dump with a segfault
> Since anyone can call the function at any time I'd argue that option (a)
> is not a good choice.
I disagree.. I prefer for things to be written with assertions, so that
when assertions are enabled we catch any suspicious behavior as soon as
possible, and when assertions are disabled, we assume "good behavior" and
can run as quickly as possible.
In this case, the spec seems to be clear that calling this function
when there is no exception pending is bogus, so that's why JCHEVM
behaves as it does.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Etienne Gagnon <eg...@sablevm.org>.
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>
>> The IBM VME comes with a check utility that complains about bad
>> practices detected in JNI code:
>>
>> Usage: -Xcheck:jni:[option[,option[,...]]]
>>...
>> pedantic perform more thorough, but slower checks
What a cool option. :-)
> This is very cool. I wonder if after some time when we get this under
> control, we should add to the standard test bed...
Actually, I'm surprised that it's not already turned on while testing...
Getting JNI usage right is not just a simple "option"; it's a
requirement according to the JNI spec. Bad JNI usage leads to undefined
behavior. SableVM has no (or minimal) protection against badly behaving
JNI code. Of course, with time, we'll add robustness checks, but this
takes time to implement. And then remains the question of how to deal
with misbehaving code... I know: "match the RI" will be suggested. :-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [vmi] JNI spec interpretation?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> The IBM VME comes with a check utility that complains about bad
> practices detected in JNI code:
>
> Usage: -Xcheck:jni:[option[,option[,...]]]
>
> all check application and system classes
> verbose trace certain JNI functions and activities
> trace trace all JNI functions
> nobounds don't perform bounds checking on strings
> and arrays
> nonfatal don't exit when errors are detected
> nowarn don't display warnings
> noadvice don't display advice
> novalist don't check for va_list reuse
> pedantic perform more thorough, but slower checks
> help print this screen
>
>
> Don't run it on the Harmony class libraries unless you have a strong
> stomach ;-)
This is very cool. I wonder if after some time when we get this under
control, we should add to the standard test bed...
geir
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Tim Ellison <t....@gmail.com>.
Archie Cobbs wrote:
> Robert Lougher wrote:
>> It's all very well bombing out with an assertion failure, but to the
>> average end-user it's still the VMs fault, especially if it works with
>> other runtimes (i.e. Suns).
>
> Sure.. sometimes theory gets trumped by practice. Then you have to decide
> which is less work: convincing 3rd parties to fix their code or
> implementing
> a hack/workaround.
>
> If there is lots of JNI code out there doing this, then you're certainly
> right that the workaround (which costs essentially nothing) would be
> easier.
The IBM VME comes with a check utility that complains about bad
practices detected in JNI code:
Usage: -Xcheck:jni:[option[,option[,...]]]
all check application and system classes
verbose trace certain JNI functions and activities
trace trace all JNI functions
nobounds don't perform bounds checking on strings
and arrays
nonfatal don't exit when errors are detected
nowarn don't display warnings
noadvice don't display advice
novalist don't check for va_list reuse
pedantic perform more thorough, but slower checks
help print this screen
Don't run it on the Harmony class libraries unless you have a strong
stomach ;-)
Actually, there is lots of repetition in the warnings/errors so we
should go ahead and fix those that we can (an easy contribution
opportunity!), for example:
JNI warning in NewObject/NewObjectV: Argument #2 is a weak reference. A
weak reference may become NULL at any time. The reference should be
promoted using NewLocalRef or NewGlobalRef and then compared to NULL
before calling NewObject/NewObjectV
Warning detected in
java/util/zip/ZipFile.getEntryImpl(JLjava/lang/String;)Ljava/util/zip/ZipEntry;
Here's an example from code in one of our dependencies:
JNI error in GetStringChars: This function cannot be called inside of a
critical section
Error detected in
com/ibm/icu4jni/converters/NativeConverter.openConverter([JLjava/lang/String;)I
I expect we need ICU4JNI to fix that themselves.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Archie Cobbs <ar...@dellroad.org>.
Robert Lougher wrote:
> It's all very well bombing out with an assertion failure, but to the
> average end-user it's still the VMs fault, especially if it works with
> other runtimes (i.e. Suns).
Sure.. sometimes theory gets trumped by practice. Then you have to decide
which is less work: convincing 3rd parties to fix their code or implementing
a hack/workaround.
If there is lots of JNI code out there doing this, then you're certainly
right that the workaround (which costs essentially nothing) would be easier.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Oliver Deakin <ol...@googlemail.com>.
Tim Ellison wrote:
> Etienne Gagnon wrote:
>
>> Oliver Deakin wrote:
>>
>>> What I mean to say is that the behaviour when the function is called
>>> without a pending exception is unspecified, and in that case I think it
>>> makes most sense to match the RI.
>>>
>> Let's say that I disagree to *impose* matching the RI's behavior for
>> undefined JNI code on Harmony VMs. In many cases, matching the RI's
>> behavior on undefined JNI would require reverse engineering way beyond a
>> point I feel comfortable with. I definitely think that Harmony's native
>> code should NEVER rely on undefined JNI behavior. JIRA reports should
>> be raised for faulty JNI code.
>>
>
> I agree.
>
Also agree. I think, as we agreed to do with the Java APIs, differences
with the RI should be examined on a case by case basis. To clarify, my
mail above wasnt intended as a blanket statement for all differences,
just for this particular one.
>
>> On the other hand, I think that it would be a nice thing to keep an
>> explicit list of "expected" behavior for some widely used (by 3rd
>> parties) "undefined JNI", so that VM implementors are *encouraged* (not
>> *forced*) to provide such workarounds. Some workarounds can be
>> expensive to implement; we had we had to implement a more expensive
>> approach for badly written JNI code that does not explicitly reserve
>> enough local native references (only 16 are guaranteed by default in the
>> spec).
>>
>
>
Agreed - and recording where we have chosen to match or differ from the
RI would be useful also.
> I agree -- and users will vote with their feet when choosing between VMs
> that make different implementation decisions. That's healthy.
>
>
>> So, I'll add a the ExceptionDecribe workaround to SableVM permanently,
>> but I do not wish feel obligated to do so. :-)
>>
>
> Of course not, that's your prerogative.
>
> Regards,
> Tim
>
>
--
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: [vmi] JNI spec interpretation?
Posted by Tim Ellison <t....@gmail.com>.
Etienne Gagnon wrote:
> Oliver Deakin wrote:
>> What I mean to say is that the behaviour when the function is called
>> without a pending exception is unspecified, and in that case I think it
>> makes most sense to match the RI.
>
>
> Let's say that I disagree to *impose* matching the RI's behavior for
> undefined JNI code on Harmony VMs. In many cases, matching the RI's
> behavior on undefined JNI would require reverse engineering way beyond a
> point I feel comfortable with. I definitely think that Harmony's native
> code should NEVER rely on undefined JNI behavior. JIRA reports should
> be raised for faulty JNI code.
I agree.
> On the other hand, I think that it would be a nice thing to keep an
> explicit list of "expected" behavior for some widely used (by 3rd
> parties) "undefined JNI", so that VM implementors are *encouraged* (not
> *forced*) to provide such workarounds. Some workarounds can be
> expensive to implement; we had we had to implement a more expensive
> approach for badly written JNI code that does not explicitly reserve
> enough local native references (only 16 are guaranteed by default in the
> spec).
I agree -- and users will vote with their feet when choosing between VMs
that make different implementation decisions. That's healthy.
> So, I'll add a the ExceptionDecribe workaround to SableVM permanently,
> but I do not wish feel obligated to do so. :-)
Of course not, that's your prerogative.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Etienne Gagnon <eg...@sablevm.org>.
Oliver Deakin wrote:
> What I mean to say is that the behaviour when the function is called
> without a pending exception is unspecified, and in that case I think it
> makes most sense to match the RI.
Let's say that I disagree to *impose* matching the RI's behavior for
undefined JNI code on Harmony VMs. In many cases, matching the RI's
behavior on undefined JNI would require reverse engineering way beyond a
point I feel comfortable with. I definitely think that Harmony's native
code should NEVER rely on undefined JNI behavior. JIRA reports should
be raised for faulty JNI code.
On the other hand, I think that it would be a nice thing to keep an
explicit list of "expected" behavior for some widely used (by 3rd
parties) "undefined JNI", so that VM implementors are *encouraged* (not
*forced*) to provide such workarounds. Some workarounds can be
expensive to implement; we had we had to implement a more expensive
approach for badly written JNI code that does not explicitly reserve
enough local native references (only 16 are guaranteed by default in the
spec).
So, I'll add a the ExceptionDecribe workaround to SableVM permanently,
but I do not wish feel obligated to do so. :-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [vmi] JNI spec interpretation?
Posted by Oliver Deakin <ol...@googlemail.com>.
Archie Cobbs wrote:
> Oliver Deakin wrote:
>>> The word "pragmatic" springs to mind. FWIW, JamVM will print nothing
>>> if no exception is pending. It didn't do this originally -- it blew
>>> up with a SEGV. I changed it because a user reported an application
>>> which didn't work with JamVM but it did with Suns VM (can't remember
>>> which application, it was a long time ago).
>>
>> This sounds right to me. As a user Id expect a call that prints
>> exception output to the screen to just print nothing and return if
>> there is no pending exception.
>>
>>> It's all very well bombing out with an assertion failure, but to the
>>> average end-user it's still the VMs fault, especially if it works with
>>> other runtimes (i.e. Suns).
>>
>> Exactly - isn't this one of those differences to undocumented RI
>> behaviour that we should try to match?
>
> There is nothing "undocumented" about this. The JNI spec says (though
> not very clearly) that you should not call this function unless you know
> there is a pending exception.
What I mean to say is that the behaviour when the function is called
without a pending exception is unspecified, and in that case I think it
makes most sense to match the RI.
>
> However, that's not to say that we shouldn't be pragmatic, though, and
> try to handle the situation gracefully.
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
>
>
--
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: [vmi] JNI spec interpretation?
Posted by Archie Cobbs <ar...@dellroad.org>.
Oliver Deakin wrote:
>> The word "pragmatic" springs to mind. FWIW, JamVM will print nothing
>> if no exception is pending. It didn't do this originally -- it blew
>> up with a SEGV. I changed it because a user reported an application
>> which didn't work with JamVM but it did with Suns VM (can't remember
>> which application, it was a long time ago).
>
> This sounds right to me. As a user Id expect a call that prints
> exception output to the screen to just print nothing and return if there
> is no pending exception.
>
>> It's all very well bombing out with an assertion failure, but to the
>> average end-user it's still the VMs fault, especially if it works with
>> other runtimes (i.e. Suns).
>
> Exactly - isn't this one of those differences to undocumented RI
> behaviour that we should try to match?
There is nothing "undocumented" about this. The JNI spec says (though
not very clearly) that you should not call this function unless you know
there is a pending exception.
However, that's not to say that we shouldn't be pragmatic, though, and
try to handle the situation gracefully.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Oliver Deakin <ol...@googlemail.com>.
Robert Lougher wrote:
> The word "pragmatic" springs to mind. FWIW, JamVM will print nothing
> if no exception is pending. It didn't do this originally -- it blew
> up with a SEGV. I changed it because a user reported an application
> which didn't work with JamVM but it did with Suns VM (can't remember
> which application, it was a long time ago).
>
This sounds right to me. As a user Id expect a call that prints
exception output to the screen to just print nothing and return if there
is no pending exception.
> It's all very well bombing out with an assertion failure, but to the
> average end-user it's still the VMs fault, especially if it works with
> other runtimes (i.e. Suns).
>
Exactly - isn't this one of those differences to undocumented RI
behaviour that we should try to match?
> Rob.
>
> On 4/5/06, Archie Cobbs <ar...@dellroad.org> wrote:
>
>> Tim Ellison wrote:
>>
>>> Understood -- my point is that "blowing up" and "corrupting internal
>>> data structures" is not something you would do by design.
>>>
>> Agreed. By using assertions you get the best of both worlds.
>> Assertions are especially useful for detecting badly behaving
>> JNI native code, which can otherwise result in very hard to
>> track down errors.
>>
>> -Archie
>>
>> __________________________________________________________________________
>> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
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: [vmi] JNI spec interpretation?
Posted by Robert Lougher <ro...@gmail.com>.
Hi,
One last point. We're talking about a single if statement here, in a
call which outputs to the screen. The overhead is miniscule.
Rob.
On 4/5/06, Robert Lougher <ro...@gmail.com> wrote:
> The word "pragmatic" springs to mind. FWIW, JamVM will print nothing
> if no exception is pending. It didn't do this originally -- it blew
> up with a SEGV. I changed it because a user reported an application
> which didn't work with JamVM but it did with Suns VM (can't remember
> which application, it was a long time ago).
>
> It's all very well bombing out with an assertion failure, but to the
> average end-user it's still the VMs fault, especially if it works with
> other runtimes (i.e. Suns).
>
> Rob.
>
> On 4/5/06, Archie Cobbs <ar...@dellroad.org> wrote:
> > Tim Ellison wrote:
> > > Understood -- my point is that "blowing up" and "corrupting internal
> > > data structures" is not something you would do by design.
> >
> > Agreed. By using assertions you get the best of both worlds.
> > Assertions are especially useful for detecting badly behaving
> > JNI native code, which can otherwise result in very hard to
> > track down errors.
> >
> > -Archie
> >
> > __________________________________________________________________________
> > Archie Cobbs * CTO, Awarix * http://www.awarix.com
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Robert Lougher <ro...@gmail.com>.
The word "pragmatic" springs to mind. FWIW, JamVM will print nothing
if no exception is pending. It didn't do this originally -- it blew
up with a SEGV. I changed it because a user reported an application
which didn't work with JamVM but it did with Suns VM (can't remember
which application, it was a long time ago).
It's all very well bombing out with an assertion failure, but to the
average end-user it's still the VMs fault, especially if it works with
other runtimes (i.e. Suns).
Rob.
On 4/5/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Tim Ellison wrote:
> > Understood -- my point is that "blowing up" and "corrupting internal
> > data structures" is not something you would do by design.
>
> Agreed. By using assertions you get the best of both worlds.
> Assertions are especially useful for detecting badly behaving
> JNI native code, which can otherwise result in very hard to
> track down errors.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Archie Cobbs <ar...@dellroad.org>.
Tim Ellison wrote:
> Understood -- my point is that "blowing up" and "corrupting internal
> data structures" is not something you would do by design.
Agreed. By using assertions you get the best of both worlds.
Assertions are especially useful for detecting badly behaving
JNI native code, which can otherwise result in very hard to
track down errors.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Tim Ellison <t....@gmail.com>.
Understood -- my point is that "blowing up" and "corrupting internal
data structures" is not something you would do by design.
So what does SableVM do if I call ExceptionDescribe() with no pending
exception?
I changed the launcher because I agree that JNI code shouldn't
misbehave, but making SableVM tolerant is good too for those cases where
the fix is not under our control etc.
Regards,
Tim
Etienne Gagnon wrote:
> By specification, the general contract for misbehavior of JNI code is
> "undefined VM behavior", which can mean anything from "blow up" to
> "corrupt internal data structures":
>
> 11.8.1 No Checking for Programming Errors
>
> The JNI functions do not check for programming errors. Passing illegal
> arguments to JNI functions results in undefined behavior. [...]
>
> Etienne
>
> Tim Ellison wrote:
>> So what should a VM do if somebody calls ExceptionDescribe() and there
>> is no pending exception?
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Etienne Gagnon <eg...@sablevm.org>.
By specification, the general contract for misbehavior of JNI code is
"undefined VM behavior", which can mean anything from "blow up" to
"corrupt internal data structures":
11.8.1 No Checking for Programming Errors
The JNI functions do not check for programming errors. Passing illegal
arguments to JNI functions results in undefined behavior. [...]
Etienne
Tim Ellison wrote:
> So what should a VM do if somebody calls ExceptionDescribe() and there
> is no pending exception?
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [vmi] JNI spec interpretation?
Posted by Tim Ellison <t....@gmail.com>.
Archie Cobbs wrote:
> Etienne Gagnon wrote:
>> It seems that the launcher assumes that it is OK to call
>> (*env)->ExceptionDescribe() even when there is no pending exception.
>
> Definitely sounds like a bug (in the launcher) to me.
I've modified the launcher to behave better.
So what should a VM do if somebody calls ExceptionDescribe() and there
is no pending exception?
(a) blow up
(b) silently ignore it, since there is nothing to describe
(c) print out something along the lines of 'no exception'
Since anyone can call the function at any time I'd argue that option (a)
is not a good choice.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Archie Cobbs <ar...@dellroad.org>.
Etienne Gagnon wrote:
> It seems that the launcher assumes that it is OK to call
> (*env)->ExceptionDescribe() even when there is no pending exception.
Definitely sounds like a bug (in the launcher) to me.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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: [vmi] JNI spec interpretation?
Posted by Etienne Gagnon <eg...@sablevm.org>.
Hi Tim,
Thanks a lot for the quick fix. :-))))
Etienne
Tim Ellison wrote:
> I've fixed it in repo revision 391436.
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [vmi] JNI spec interpretation?
Posted by Tim Ellison <t....@gmail.com>.
Etienne Gagnon wrote:
> Hi,
>
> I have started playing with the launcher and SableVM. I have a little
> fun trying to figure out how to debug the thing using DDD. The execv
> trick was a nasty one to get over...
Glad you are having fun ;-)
> Anyway, now that it works, I am
> facing a JNI specification interpretation problem.
>
> It seems that the launcher assumes that it is OK to call
> (*env)->ExceptionDescribe() even when there is no pending exception.
>
> My reading of the JNI spec is different. The spec says:
>
> "... This function has the side effect of clearing *the* pending
> exception..."
>
> This contrasts with ExceptionClear which says:
>
> "...Clears *any* pending exception... If no exception..."
>
> Therefore, I always assumed that the necessarily was a pending
> exception. One cannot talk about *the* pending exception, if there is
> not necessarily one. Otherwise, the spec would have said: ...clearing
> any pending exception...
>
>
> What do others think? Should I file a bug against the launcher, i.e:
>
> native-src/shared/launcher/main.c line 1006
I've fixed it in repo revision 391436.
But if people want to debate whether `describe` should be a noop or
error where there is no pending exception, then go ahead.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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