Review Request: JDK-8157464: StackWalker.getCallerClass() is not

Mandy Chung mandy.chung at oracle.com
Tue Sep 13 22:18:02 UTC 2016


Hi Daniel,

StackWalker::getCallerClass is a convenient method to find the caller class and is specified to skip the hidden frames (that’s the caller we are interested in).   Since StackWalker only asks VM to fill in classes, the library can’t tell if it’s an anonymous class or not.

Your question prompts me to revise the patch and simply skip the hidden frame if this stack walk is to lookup caller class to match the specification.  I think this is a better fix:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.02/ 

We may re-examine this in the future if getCallerClass should get MemberName like the walk method such that we can determine if it’s a hidden frame and the performance difference.

Mandy

> On Sep 13, 2016, at 11:54 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Mandy,
> 
> This looks good to me.
> But I wonder about these 5 lines - isn't this introducing a change
> of behavior if the caller is an anonymous class?
> 
> 149       InstanceKlass* ik = method->method_holder();
> 150       if (ik->is_anonymous()) {
> 151         // use the host class as the caller class
> 152         ik = ik->host_klass();
> 153       }
> 
> What is the reason for returning the host class instead?
> 
> best regards,
> 
> -- daniel
> 
> On 13/09/16 19:24, Mandy Chung wrote:
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01
>> 
>> This revises the proposal posted some time ago [1].
>> 
>> StackWalker::getCallerClass is a convenient method to find the caller class. It will return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass, as it’s currently specified.
>> 
>> This issue is related to MethodHandle for @CallerSensitive method.  It behaves as if the caller is the lookup class and in the current implementation, the actual caller class is not the lookup class but a generated class.
>> 
>> One intended usage of StackWalker::getCallerClass is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader).
>> 
>> Given that StackWalker::getCallerClass is not expected to be used by any @CS method, this patch proposes to catch and throw an exception if StackWalker::getCallerClass is called by a @CS method.  This will allow time to revisit this when such need is identified.
>> 
>> thanks
>> Mandy
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042345.html
>> 
> 



More information about the core-libs-dev mailing list