On Mar 2, 2013, at 12:46 AM, Jeroen Frijters <[email protected]> wrote:
> This is really great. I've been using an annotation for caller sensitive
> methods for many year in IKVM as a performance enhancement and I can say that
> my experiences with my simple mechanism are really great.
Hi Jeroen. I'm glad you (and others) like this. Your idea makes good sense,
even for Hotspot.
Remi's idea (using invokedynamic) makes a good proof of concept, too. But
because we use getCallerClass to observe a non-forgeable caller identity, the
@CS mechanism has to be something that works "underneath" any visible bytecode
pattern, at least in the caller.
Thinking out loud... In JVM terms, a @CS method might also be implemented with
two entry points like this:
class ImportantSystemAPI {
...
/** Returns the name of the class of the calling method. */
@CallerSensitive
public static String currentClassName() {
return currentClassName(Reflection.getCallerClass());
}
private static String currentClassName(Class caller) {
return caller.getName();
}
}
The link-resolver could be taught to look for this pattern, and accordingly
tweak call sites (invokestatic instructions). The call site would have an
extra parameter appended, and would be bound to the private method instead of
the public one.
Interestingly, the current version of the Hotspot JVM has a mechanism for
appending an extra reference argument in selected calls (used for MH.invoke*
and invokedynamic itself). The decision to append the extra argument (known as
the "appendix") is made at call-site link time (<= first time execution of the
call site). In this case, we might append the class of the caller, or (as in
your design) something which allows lazy evaluation and supports derived values
(class loader instead of class).
In fact, the derived values are more interesting than the class itself. And if
we are ever to share linkage information across classes (a desirable thing,
judging by experience in the ME world) then we need to be able to make resolved
@CS sites be applicable across a group of classes (all sharing a common package
or CL).
Thanks for the discussion!
— John
