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
