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.

Reply via email to