[PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

[Mandy Chung]

On 9/20/13 2:24 AM, Peter Levart wrote:
> Mandy: I like the API. It covers the use-cases optimally. I can see 
> how StackStreamcould be implemented with a single JNI -> Java callback 
> per StackFrameInfo...  Why not using the same call-back principle for 
> Throwable API too. 

One important design goal is to minimize the VM transition (did I 
mention it in an early mail?  My apology if I missed that).  One 
approach is to fetch stack frames one batch at a time and the users can 
give the VM hint to determine a good size of each batch and allocate an 
estimated size of buffer for the stack frames.  To filter and find one 
frame only, the implementation should pass a smaller buffer for JVM to 
fill the stack frames in one single VM transition.  To walk the entire 
stack, it could be like Throwable.fillInStackTrace to pass a bigger 
array for VM to fill.

The VM transition has a costand that's the performance issue that Nick 
fixed in Throwable.getStackTrace(). Instead of calling VM to fill one 
element at a time, his patch has the VM to fill the entire 
StackTraceElement array.  To get a stack frame, the VM may have to flush 
the registers and other machinery out - this is the cost that should be 
avoided if the user is not interested in the entire stack trace.

> Instead of implementing Throwable.walkStackTracein terms of 
> getStackTrace it could be the other way around. For completeness, 
> getCaller() and firstCaller() could also be added to Throwable 
> although we don't yet have a use-case for that. 

Will give more thought on this.  There are open issues and discussion to 
follow on my proposal.

I sent this out last night because I want to share the proposal early 
enough to get feedback.  Thank you, Peter, for your replies to answer 
some of the questions.

Mandy