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
