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