BoundMethodHandle Klass and JVMTI heap walking

[John Rose]

On Aug 2, 2011, at 6:44 PM, Mark Roos wrote:

> We are using the JVMTI api FollowReferences to collect object information.  In this 
> api we can set a klass which limits the objects reported.  For some reason we get instances of the 
> klass we set and BoundMethodHandle instances. 

BoundMethodHandle is a private, implementation-specific subclass of MethodHandle.

Consider this example code:
  Object x = new Object();
  MethodHandle mh1 = identity(Object.class).bindTo(x);
  MethodHandle mh2 = lookup().bind(x, "hashCode", methodType(int.class));
  assert(mh1.invokeExact() == x);
  assert((int) mh2.invokeExact() == x.hashCode());
  System.out.println(mh1.getClass().getName());  // maybe java.lang.invoke.BoundMethodHandle
  System.out.println(mh2.getClass().getName());  // maybe java.lang.invoke.BoundMethodHandle also

Both mh1 and mh2 are going to be node structures which include a "hidden" pointer to x.
In OpenJDK 7, mh1 and mh2 might be BoundMethodHandles, but don't take that to the bank.

In any case, I would expect FollowReferences to report that x has a reference from both mh1 and mh2 (or a substructure thereof).

> Are they somehow masquerading as a different class ( they are binding methods of the klass we 
> are inspecting) or is this just an oversight?   

The exact concrete type of a MethodHandle is *not* defined by JSR 292; it is left open to implementors.

If you run the above code on IBM's J9, you'll get a different class name.

-- John