Hi Mandy,
Sorry I was not clear.
I'm proposing the following changes:
StackFrameInfo.java:
100 public OptionalInt getLineNumber() {
101 ensureMethodInfoInitialized();
102 return lineNumber != -1 && lineNumber != -2
? OptionalInt.of(lineNumber)
: OptionalInt.empty();
103 }
StackWalker.java:
175 public default StackTraceElement toStackTraceElement() {
176 return new StackTraceElement(getClassName(),
getMethodName(),
177 getFileName().orElse(null),
178 getLineNumber()
.orElse(isNativeMethod() ? -2 : -1));
179 }
best regards,
-- daniel
On 13/11/15 18:58, Mandy Chung wrote:
On Nov 13, 2015, at 9:55 AM, Daniel Fuchs <daniel.fu...@oracle.com> 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 <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
