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

Coleen Phillimore coleen.phillimore at
Tue Sep 13 21:32:04 UTC 2016

On 9/13/16 2:54 PM, Daniel Fuchs 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?

Somehow I think you want to see all the lambda classes in the stack 
trace, or skip them but the host class might be confusing because it's 
something like  java/lang/invoke/LambdaForm a lot of the time.   At 
least you'd get java.lang.invoke.LambdaForm$BMH/1170794006 which has a 
little more information.

+ THROW_MSG_0(vmSymbols::java_lang_UnsupportedOperationException(),

I think you need ResourceMark rm(THREAD); above this line.

I can't review the test because I'm not sure what it's doing.  Does it 
create a module just for the test?

Otherwise, I think the hotspot code looks fine.

> best regards,
> -- daniel
> On 13/09/16 19:24, Mandy Chung wrote:
>> Webrev:
>> 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] 

More information about the hotspot-runtime-dev mailing list