> On Nov 13, 2015, at 9:55 AM, Daniel Fuchs <[email protected]> wrote:
>
> Hi Mandy,
>
> StackFrameInfo.java:
>
> 100 public OptionalInt getLineNumber() {
> 101 ensureMethodInfoInitialized();
> 102 return lineNumber != -1 ? OptionalInt.of(lineNumber) :
> OptionalInt.empty();
> 103 }
>
> If lineNumber is -2 then empty should probably be returned too.
lineNumber == -2 is used to indicate a native method.
-1 is unavailable.
>
> Which means that the following code code in StackWalker.StackFrame
> would need to be changed accordingly:
>
> 175 public default StackTraceElement toStackTraceElement() {
> 176 return new StackTraceElement(getClassName(), getMethodName(),
> 177 getFileName().orElse(null),
> 178 getLineNumber().orElse(-1));
> 179 }
>
> The other option would be to document -2 as a special value
> in StackFrame.getLineNumber() but that would be ugly?
>
StackTraceElement constructor takes -2 line number for native method.
Mandy
> best regards
>
> -- daniel
>
> -- 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 <[email protected]> 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
>>
>
