The comment was incorrect. It should be: // this was the last frame decoded in the previous batch
Mandy > On Nov 13, 2015, at 9:36 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Mandy, > > Looking at stackwalk.cpp, I'm puzzled by this comment at line 465: > > http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.01/hotspot/src/share/vm/prims/stackwalk.cpp.html > > 463 vframeStream& vfst = anchor.vframe_stream(); > 464 if (!vfst.at_end()) { > 465 vfst.next(); // skip java.lang.StackStream::moreStackWalk > > Is that because the previous call to decode_frames is supposed > to leave the stream at the last recorded frame - without advancing? > So the frame at vfst had already been returned in the previous batch? > > If so I find the comment at line 465 a bit misleading. > > best regards, > > -- daniel > > On 13/11/15 16:21, Mandy Chung wrote: >> A revised webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.01 >> >> javadoc: >> >> http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html >> >> The main change in this version is mostly in the hotspot change to >> incorporate Coleen’s suggestion: >> 1. Move the new Klasses to systemDictionary as well known classes. >> 2. Cache the doStackWalker method >> 3. Move StackFrameInfo::mid, version, cpref fields as VM injected fields as >> they are not needed by Java. >> These fields are interim for performance measurement to compare the cost of >> MemberName initialization. >> >> The microbenchmark running StackWalker::walk shows 3-4.5X slower due to the >> use of MemberName. I suspect the overhead might be due to the MemberName >> initialization has to handle unresolved and unlinked methods. For stack >> walker, the method has been linked and it may be a low hanging fruit to fix >> in the VM. >> >> 4. Updates the javadoc of StackWalker::getCallerClass to reflect filtering >> of reflection and MethodHandle frames. >> >> Open question: >> - is it useful to have an option to configure filtering/showing >> java.lang.invoke frames? A user can filter it themselves and I don’t think >> it’s highly needed and we can add it in the future if needed. >> >> Mandy >> >> >>> On Nov 9, 2015, at 6:32 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: >>> >>> 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 >> >