RFR (S): 8196022: java.lang.VerifyError is thrown instead of java.lang.IllegalAccessError
david.holmes at oracle.com
Sat Jan 27 06:33:46 UTC 2018
On 26/01/2018 10:49 AM, Vladimir Ivanov wrote:
> It's a followup on JDK-8188145  which fixed what exceptions are
> thrown. It (unexpectedly :-)) fixed inaccuracy there: MemberName
> resolution code on JDK side converted most of LinkageErrors into
> IllegalAccessErrors, but after JDK-8188145  there's no upcall anymore
> when resolution fails, so exceptions are reported as is which is the
> right thing.
The "right thing" is determined by the spec. If we've been doing the
"wrong thing" all this time then that is a problem and the fix may be to
the spec rather than the code. Can you clarify please what part of the
spec we are following here such that we know what exceptions should be
thrown, from where? If these are calls from Java MH code then we need to
examine the specs for those methods too.
> The fix cleans JDK part to behave the same way.
I'm unclear how this fix changes the JDK side. Is it because it
tranforms LinkageErrors, and you no longer allow LinkageErrors to pass
through? (Does that make the JDK code "dead"?).
Also the CR talks about VerifyError being thrown, but I didn't spot
anything that would be dealing with that case ?? Is VerifyError the
correct/expected exception now?
> Also, fixed MethodHandles::resolve_MemberName() to handle corner cases
> when empty handle is returned, but no exception is thrown. An exception
> should be thrown in that case as it is in MHN_resolve_Mem.
> As a simplifying change, converting ClassNotFoundException to
> NoClassDefFoundError was added to avoid dealing with it on JDK side.
> Testing: hs-tier1, hs-tier2, vm.defmeth, jck-runtime-10,
> jdk/java/lang/invoke/, hotspot/runtime/invokedynamic/
> Best regards,
> Vladimir Ivanov
>  https://bugs.openjdk.java.net/browse/JDK-8188145
More information about the hotspot-runtime-dev