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

[Mandy Chung]

Yes that’s one option.

JVM_STACKWALK_FILL_CLASS_REFS_ONLY is not necessarily used to get caller class.  For example, AccessControlContext is interested in protection domains.  We could build a specialized impl class to walk the stack fetching Class<?> only whereas getCallerClass will stop walking after a few top frames.   So a different bit will enable future experiment.  Having said that, the assert should be reverted and minor adjustment:

@@ -140,6 +143,13 @@
       fill_stackframe(stackFrame, method, bci);
     } else {
       assert (use_frames_array(mode) == false, "Bad mode for get caller class");
+      if (get_caller_class(mode) && index == start_index && method->caller_sensitive()) {
+        ResourceMark rm(THREAD);
+        THROW_MSG_0(vmSymbols::java_lang_UnsupportedOperationException(), 
+          err_msg("StackWalker::getCallerClass called from @CallerSensitive %s method",
+                  method->name_and_sig_as_C_string()));
+      }
+

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.03/

Mandy

> On Sep 13, 2016, at 4:09 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi, Mandy
> 
> Is a new JVM_STACKWALK_GET_CALLER_CLASS bit needed in jvm.h?  AFAICT, JVM_STACKWALK_FILL_CLASS_REFS_ONLY is already only set for the getCallerClass() case.
> 
> Could the new get_caller_class() instead check if JVM_STACKWALK_FILL_CLASS_REFS_ONLY is set?  (Yes, this would be a third function checking the same thing, along with need_method_info() and use_frames_array()...)
> 
> -Brent
> On 09/13/2016 03:18 PM, Mandy Chung wrote:
>> 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
>>>> 
>>> 
>> 
>