RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
mandy.chung at oracle.com
Tue Mar 19 20:14:41 UTC 2013
I do a partial review in particular to make sure the jdk and hotspot
change are in sync.
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
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.
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
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.
On 3/14/13 8:31 PM, Christian Thalinger wrote:
> [This is the HotSpot part of JEP 176]
> 7198429: need checked categorization of caller-sensitive methods in the JDK
> More information in JEP 176:
More information about the core-libs-dev