[PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8
mandy.chung at oracle.com
Fri Sep 20 18:00:28 UTC 2013
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.
More information about the core-libs-dev