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

[Christian Thalinger]

Thank you, Vladimir.  -- Chris

On May 3, 2013, at 5:25 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Looks good.
> 
> Thanks,
> Vladimir
> 
> On 5/3/13 4:45 PM, Christian Thalinger wrote:
>> 
>> On May 2, 2013, at 8:01 PM, John Rose <john.r.rose at oracle.com
>> <mailto:john.r.rose at oracle.com>> wrote:
>> 
>>> On May 2, 2013, at 7:32 PM, Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com <mailto: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
>>