RFR 8166974: invokedynamic implementation should not wrap Errors

[Stuart Marks]

Hi Paul,

I took a look at the jdk changes. They look good to me.

One section of code gave me pause, which is the throw of ClassCastException at 
339 of CallSite.java, and the throw of the exception returned from 
wrongTargetType() at 344 of CallSite.java. This appears odd given the "rethrow 
any Error and wrap anything else in BSME" rule. But these throws are caught by 
the catch of Throwable below, which does the wrap and throw of BSME.

This arrangement was already present in the code.

Usually I wrinkle my nose at a throw that's caught by a catch clause later on, 
but in this case it's not obvious what would be better. Maybe a comment is 
warranted?

I didn't look too closely at the hotspot changes; somebody else should review them.

s'marks



On 10/14/16 3:08 PM, Paul Sandoz wrote:
> Hi,
>
> Please review:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-jdk/webrev/
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-hotspot/webrev/
>
> The JMV spec was recently updated to state the following in the Linkage Exceptions section of the invokedynamic instruction:
>
> https://bugs.openjdk.java.net/browse/JDK-8164693
>
> "If resolution of the symbolic reference to the call site specifier throws an exception E, the invokedynamic instruction
> <add>throws E if the type of E is Error or a subclass, else it</add>
> throws a BootstrapMethodError that wraps E."
>
> "Otherwise, during the continuing resolution of the call site specifier, if invocation of the bootstrap method completes abruptly (§2.6.5) because of a throw of exception E, the invokedynamic instruction
> <add>throws E if the type of E is Error or a subclass, else it</add>
> throws a BootstrapMethodError that wraps E.”
>
> Namely if linkage fails due to the throwing of an Error or subclass then that Error is re-thrown by the indy. All other types of exception that may be thrown are wrapped in BootstrapMethodError that is then thrown. This means that errors such as ThreadDeath or OutOfMemoryError will pass through unwrapped.
>
> This is a behavioural change but we anticipate one that should have minimal impact.
>
>
> This change was motivated by updates to some classes using VarHandle for which VarHandle method linkage unduly wrapped some errors (like ThreadDeath) in LinkageError. (Note the same will apply for MethodHandle invoke linkage, or MethodHandle/MethodType resolution in the constant pool, or for string concatenation which now leverages indy). VarHandle/MethodHandle linkage error behaviour is tracked by another issue, https://bugs.openjdk.java.net/browse/JDK-8163553, which should not require any specification change.
>
> Thanks,
> Paul.
>