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 <[email protected]>
> 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 <[email protected]> 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
>>>>
>>>
>>
>
