RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK

[John Rose]

On Mar 19, 2013, at 1:14 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value.  Should they be different?
> 
> 1057     MN_CALLER_SENSITIVE     = 0x00100000, // @CallerSensitive annotation detected
> 1061     MN_SEARCH_SUPERCLASSES  = 0x00100000, // walk super classes

That's OK; they are used with different arguments, as the nearby comments point out.

> method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader?  Does it only check annotations if the class of that method is defined by the null class loader?  Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive.

Oops, that needs fixing.

For simplicity, I suggest you adjust the boolean 'privileged' that controls the ad hoc category of code that benefits from the annotation parsing.  The important property of such code is that it is statically configured with the JVM, not dynamically loaded.

> If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS.  Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)?

Maybe not, if it would involve reparsing the annotations.  The error message can mention that the offending method is off the BCP so that even if it _were_ annotated the annotation would not count.  We don't need a very user-friendly message here, as long as it points out that there is an offending off-label use of a JVM primitive.  Nobody calls JVM_GetCallerClass by accident, and even if an end user is the unlucky discoverer, if the JVM message says "illegal internal method call" or some such, the bug should be clear enough.

> jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future.  I am fine with either approach but just to bring it up.

Good point.  I'm fine with either option.

— John