Code Review for JEP 259: Stack-Walking API

[Dmitry Samersoff]

Mandy,

Native part looks good for me.

javaClasses.cpp:

1. It might be good to create a helper inline function for

  int bci_version = stackFrame->int_field(bci_offset);
  int version     = BackTrace::version_at(bci_version);

2. java_lang_StackFrameInfo::fill_methodInfo

  CHECK macro left methodInfo partially initialized, not sure it's OK.

javaClasses.inline.hpp:

78 You can use the same pattern as in assert:

    if ((jushort)version != version) version = USHRT_MAX;

117 Is it possible to add comment about +1000000 magic?

jvm.cpp:

627 missed space around =

-Dmitry


On 2015-11-10 05:32, Mandy Chung 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
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.