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
>> 
> 

Reply via email to