Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.01/index.html
I added a new StackFrame::getByteCodeIndex method to return bci and updatedgetFileName and getLineNumber to have the same returned type as in StackTraceElement. From usage perspective, the caller has to prepare and handle the information is unavailable and I think it would typically log some token to represent the unavailable case and might well use null and negative value. This patch would save the creation of short-lived Optional object that might help logging filename/linenumber case. I’m working on a new test to verify bci and line number to be included in the next revision. Mandy > On Apr 11, 2016, at 2:22 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html > > StackFrame::getFileName and StackFrame::getLineNumber are originally proposed > with the view of any stack walking code can migrate to the StackWalker API > without the use of StackTraceElement. > > File name and line number are useful for debugging and troubleshooting > purpose. It has additional overhead to map from a method and BCI to look up > the file name and line number. > > StackFrame::toStackTraceElement method returns StackTraceElement that > includes the file name and line number. There is no particular benefit to > duplicate getFileName and getLineNumber methods in StackFrame. It is > equivalently convenient to call > StackFrame.toStackTraceElement().getFileName() (or getLineNumber). > > This patch proposes to remove StackFrame::getFileName and > StackFrame::getLineNumber methods since such information can be obtained from > StackFrame.toStackTraceElement(). > > Mandy
