RFR (S) : 8025260 : Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME)

[Vladimir Ivanov]

David,

Small suggestion about the test: why not make ByteClassLoader, I & C 
package-private and move them into TestAMEnotNPE.java?

Best regards,
Vladimir Ivanov

On 9/26/13 5:01 AM, David Chase wrote:
> webrev: http://cr.openjdk.java.net/~drchase/8025260/webrev.00/
>
> problem: Various places in hotspot adhere to a convention that if a method code pointer (store in a vtable, for instance) is null, then what would be a NullPointerException is instead converted to an AbstractMethodError.  This can be seen in vtableStubs_x86.cpp (search for ame_addr) and templateTable_x86_32.cpp (search for no_such_method), and also Sparc.  However, for methodhandles this convention was not followed and instead a NullPointerException is thrown, which is clearly wrong.
>
> The bug itself causes 24 failures in the ute defmeth benchmark.
> There is a related bug where NullPointerException is thrown instead of IllegalAccessError, and the fix for this bug converts those to AbstractMethodError, which is differently wrong, but not as completely wrong as NullPointerException.  See https://bugs.openjdk.java.net/browse/JDK-8016839 .  That needs to be handled elsewhere, or by passing more context in to the code that deals with this null pointer.
>
> fix:
> add a check and a throw, once per architecture.
> extract a small self-contained test from defmeth
>
> testing:
> 1) try new against old and new to ensure that the test is a test.
> 2) manually test across Sparc and x86
> 3) test against a variety of Sparc and x86 using jprt.
>
> David
>