RFR (S): 7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact

[Christian Thalinger]

On May 2, 2013, at 8:01 PM, John Rose <john.r.rose at oracle.com> wrote:

> On May 2, 2013, at 7:32 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> The exception is then caught and forwarded on the return from lookup() call and before the call to a native function.
> 
> Here are some interesting points of JVM trivia which relates to the unusual control flow in this code:
> 
> JVMS 5.4.3 says, "If an attempt by the Java virtual machine to resolve a symbolic reference fails because an error is thrown that is an instance of LinkageError (or a subclass), then subsequent attempts to resolve the reference always fail with the same error that was thrown as a result of the initial resolution attempt."
> 
> In other words, for each symbolic reference you get just one chance to resolve it successfully.  If it fails to resolve, you throw the same error every time in the future.  (This means you need a failure record somewhere in the JVM.)
> 
> Since UnsatisfiedLinkError is a subclass of LinkageError, you might think this rule applies.  But it doesn't.  When you resolve a native call site, you succeed if you get access to the Java side of the native method.  A subsequent operation, at runtime not link time, determines whether the call into native code succeeds.
> 
> The JVMS says this for the invoke instructions, under Runtime Exceptions (not Linking Exceptions):  "Otherwise, if the selected method is native and the code that implements the method cannot be bound, invokespecial throws an UnsatisfiedLinkError."  The placement of this language implies that the UnsatisfiedLinkError can be repeated.  It can even go away, if somebody does a System.loadLibrary call that happens to supply the right native entry point (or so I think).  JNI supplies a way to unload native methods also, so a bound native method can apparently change state between ULE-throwing and normal function any number of times.
> 
> In any case, this is why there is a funny extra degree of freedom, and an extra binding pass, in the JVM for the native function binding of a Java native method.

True but we should let throw_unsatisfied_link_error do the throwing and not NativeLookup::lookup().  This seems odd and confusing.

I will file a bug and we can fix that later.

Here are some comment changes:

http://cr.openjdk.java.net/~twisti/7196277/

-- Chris

> 
> — John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130503/1be4b60e/attachment.html