RFR: 8262400: runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails in test_ame5_compiled_vtable_stub with wrapper

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Feb 23 20:47:15 UTC 2022



On 2/23/22 3:00 PM, David Holmes wrote:
> On Wed, 23 Feb 2022 16:50:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>> If the vtable stub function is deoptimized, it will get the error message from the interpreter, which doesn't include the receiver class.   Disable this class if DeoptimizeALot is passed in.
> Hi Coleen,
>
> As a test fix this seems fine. But is it worth trying to make the interpreter and compiler messages more alike?

I thought that would be a better fix, but unfortunately, this:

// This method is called from the "abstract_entry" of the interpreter.
// At that point, the arguments have already been removed from the stack
// and therefore we don't have the receiver object at our fingertips. 
(Though,
// on some platforms the receiver still resides in a register...). Thus,
// we have no choice but print an error message not containing the receiver
// type.
JRT_ENTRY(void, 
InterpreterRuntime::throw_AbstractMethodErrorWithMethod(JavaThread* current,
Method* missingMethod))
   ResourceMark rm(current);
   assert(missingMethod != NULL, "sanity");
   methodHandle m(current, missingMethod);
   LinkResolver::throw_abstract_method_error(m, THREAD);
JRT_END

Seems not practical.
Thanks for looking at this.
Coleen

>
> Thanks,
> David
>
> -------------
>
> Marked as reviewed by dholmes (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/7596



More information about the hotspot-runtime-dev mailing list