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

[Vladimir Kozlov]

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
>