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

Christian Thalinger christian.thalinger at oracle.com
Wed Sep 25 20:26:14 PDT 2013

Could we use the same jump-over code for SPARC too?  It helps to keep the ports a similar as possible.

A general comment:  prefixing labels with L_ makes them easier to spot and follow the control flow.

On Sep 25, 2013, at 6:01 PM, David Chase <david.r.chase at oracle.com> 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

More information about the hotspot-compiler-dev mailing list