problems with sun.reflect.Reflection.getCallerClass(int)

Mandy Chung mandy.chung at oracle.com
Mon Jul 22 10:27:17 UTC 2013


On 7/22/2013 3:37 PM, Jochen Theodorou wrote:
> Am 20.07.2013 03:41, schrieb Mandy Chung:
>> Hi Jochen,
>>
>> I read through the thread in mlvm-dev [1] that has a good discussion
>> there.   I have filed a RFE:
>>     8020785: caller-sensitive methods to skip dynamic generated frames
>> and look up the true caller
>>
>> This seems that java.lang.instrument might be an appropriate place for
>> this support.  This certainly requires further investigation.
>>
>> Mandy
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-July/005387.html
>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020785
>
> can you explain a little how instrumentation could help here? Of 
> course I don't expect a full solution, but the idea would be helping.

As I understand your use case, what you need is to tell the system to 
skip some specific frames when a caller-sensitive method is looking up 
the caller which the functionality depends on (e.g. 
ResourceBundle.getBundle and Class.forName uses the caller's loader to 
find class/resource).  You currently achieve this by walking the stack.  
I like Charles's suggestion to teach JVM about language-specific stack 
traces.    Instrumentation agents probably do something similar to skip 
its own runtime classes / packages.

The current hotspot implementation skips sun.reflect.* and a few other 
specific classes to determine the caller class.   I think 
java.lang.instrument seems an appropriate place for this kind of 
functionality and provide a way to extend the whitelist to skip and pass 
it to the JVM.  This is really just a rough idea and there may be issues 
to be investigated.

I didn't have time to look into this RFE as I have been very busy on 
other high priority works.   Whoever works on this RFE will certainly 
discuss the proposals in core-libs-dev and get feedbacks.

Mandy




More information about the core-libs-dev mailing list