Background: I'm the author of a HotSpot LogCompilation visualiser called JITWatch and I'm refactoring the parsing engine. I have a question on matching LogCompilation method signatures to Class.getDeclaredMethod()
signatures, specifically about matching the void return type.
Given the HotSpot LogCompilation output snippet:
<nmethod compile_id='48' compile_kind='c2n' entry='0x00007f01fc3f41c0'
size='328' address='0x00007f01fc3f4090' relocation_offset='296'
consts_offset='328' insts_offset='304'
method='java/lang/invoke/MethodHandle linkToStatic
(Ljava/lang/Object;ILjava/lang/invoke/MemberName;)V'
bytes='0' count='0' iicount='0' stamp='0.840'/>
Which indicates a compilation (using a native wrapper) of the method linkToStatic
on class java.lang.invoke.MethodHandle
which takes as parameters
java.lang.Object, int, java.lang.invoke.MemberName
and returns void
The only method it could possibly match on java.lang.invoke.MethodHandle
has signature:
static native java.lang.Object linkToStatic(java.lang.Object...) throws java.lang.Throwable;
Which has java.lang.Object
varargs parameters (matches the LogCompilation parameters) but declares a java.lang.Object
return type.
Is it legal to match the void
return from the LogCompilation signature with java.lang.Object
for the reason that:
Object.class.isAssignableFrom(Void.class); // returns true
I'd be grateful if somebody could explain the mechanics behind the void return type.
Thanks,
Chris
The linkToStatic
method is a signature polymorphic method. Their signature varies depending on the call site.
HotSpot will internally create new Method
objects with the signature required by a call site (see SystemDictionary::find_method_handle_intrinsic
).
The method
attribute you see for this nmethod
is the string representation of such a Method
: its signature (including the return type) is specialized to a specific call site.
So in general it is not ok to match the void
return type with java.lang.Object
and you probably need a special case to match signature polymorphic methods.