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.christ...@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.fu...@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 >>>> >>> >> >