One other kind of stack metadata that is missing (yet is present with
external tools such as jstack etc.) is ancillary data about stack frames
indicating whether the frame holds or is waiting on a lock. I'm not
sure whether it's practical to add all this stuff though,
performance-wise, unless maybe it is made optional with an option flag.
On 11/12/2015 09:29 AM, Jason Mehrens wrote:
Mandy,
Forgive my ignorance on this subject and impacts but, would it be possible to
include more metadata methods in the StackWalker.StackFrame interface such as
getParameterTypes/parameterArray and getReturnType/returnType? Ideally, I
really would like these methods for StackTraceElement since knowing the exact
parameter types allows the caller to lookup the method to examine all the
method metadata which is useful for logging not only in output but for use in
stacktrace reduction algorithms.
Thanks,
Jason
________________________________________
From: core-libs-dev <[email protected]> on behalf of Mandy Chung
<[email protected]>
Sent: Monday, November 9, 2015 8:32 PM
To: core-libs-dev; [email protected]
Subject: Code Review for JEP 259: Stack-Walking API
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
--
- DML
