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


Reply via email to