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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
