Here is the latest version of the javadoc and code. Speak now or forever hold your peace.
Ralph > Begin forwarded message: > > From: Mandy Chung <mandy.ch...@oracle.com> > Subject: Code Review for JEP 259: Stack-Walking API > Date: November 9, 2015 at 7:32:49 PM MST > To: core-libs-dev <core-libs-...@openjdk.java.net>, > hotspot-runtime-...@openjdk.java.net > > javadoc: > > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html > > webrev: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ > > Overview of the implementation: > When stack walking begins, the StackWalker calls into the VM to anchor a > native frame (callStackWalk) that will fetch the first batch of stack frames. > VM will then invoke the doStackWalk method so that the consumer starts > getting StackFrame object for each frame. If all frames in the current batch > are traversed, it will ask the VM to fetch the next batch. The library side > is doing the filtering of reflection frames. For this patch, the VM filters > of the hidden frames and also filter out Throwable::init related frames for > stack trace. > > Ultimately we will move to these built-in logic out from the VM to the > library but I’d like to separate them as future works. > > This patch also includes the change for Throwable to use StackWalker but it’s > disabled by default. To enable it, set -Dstackwalk.newThrowable=true. The > VM backtrace is well tuned for performance. So we separate the switch of > Throwable to use StackWalker as a follow-on work: > JDK-8141239 Throwable should use StackWalker API to capture the backtrace > > MemberName initialization is one source of overhead and we propose to keep > the VM flag -XX:-MemberNameInStackFrame for the time being for the > performance work to continue for JDK-8141239. > > Thanks > Mandy
