RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called.

[Christian Thalinger]

On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/
> 7 lines changed: 5 ins; 1 del; 1 mod
> 
> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo:
> assert(m.vminfoIsConsistent());
> 
> After that check, class redefinition is broken - it's still possible to invoke old version of a method.
> 
> Analysis from Serguei:
> "The problem is here:
> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& info) {
>  . . . . . . . .
>  m->method_holder()->add_member_name(m->method_idnum(), mname);
> 
>  return mname();
> }
> 
> The call to add_member_name() resets the member name at the index m->method_idnum(). After that one of the two member names with the same method_idnum() is out of the MNT and is not updated when the method is redefined."

As I understand this the problem is calling MethodHandles::init_method_MemberName which installs a new MemberName instance in the MemberNameTable.  Correct?

If that's the case then there is a potential race here.

+     x = m->method_holder()->get_member_name(m->method_idnum());
+     if (x == NULL) {
+       Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL);
        x = MethodHandles::init_method_MemberName(mname2, info);
      }

Racing threads can get back null when calling get_member_name and then install different MemberName objects in the table.

> 
> The fix is to check whether there's already a member name associated with the before creating a new one.
> 
> Testing: failing test.
> 
> Contributed-by: sspitsyn, vlivanov
> 
> Best regards,
> Vladimir Ivanov
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004