JEP 176: Mechanical Checking of Caller-Sensitive Methods

[John Rose]

On Mar 2, 2013, at 12:46 AM, Jeroen Frijters <jeroen at sumatra.nl> 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