I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven’t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7.
Ralph > On Apr 13, 2016, at 10:27 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > It is good to know Log4J is planning to use StackWalker. > > Thanks for the feedback. I will reconsider. > > One thing to mention is the patch went in jdk9/hs-rt that will show up in > jdk9/dev some time that changes the implementation to create > StackTraceElement to get filename and line number. The object allocation > should be cheap that does create short-lived objects. The main motivation of > JDK-8153123 was to simplify the hotspot implementation that the runtime team > had concern about. There is an open issue to follow up the performance > (JDK-8153683). It’d be helpful to get your feedback on using StackWalker API > and the performance data. > > Mandy > >> On Apr 13, 2016, at 6:51 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> I had planned on using StackWalker to generate the location information for >> every logging event. It seems that this change would thus cause the creation >> of a new StackTraceElement for every logger event. That seems wasteful. >> Log4j is currently in the process of trying to reduce the number of objects >> that are created while logging as it has a significant impact on garbage >> collection. So I am also in favor of getting the filename and line number >> directly from the StackFrame. >> >> Ralph >> >>> On Apr 12, 2016, at 5:15 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: >>> >>> >>>> On Apr 12, 2016, at 1:34 AM, Rémi Forax <fo...@univ-mlv.fr> wrote: >>>> >>>> Hi Mandy, >>>> I really don't like this patch. >>>> >>>> Being forced to call toStackElement to get the line number is counter >>>> intuitive. >>>> I would prefer the two methods to not return Optional but an int and a >>>> String with the same convention as StackElement if the point of this patch >>>> is to remove the dependency to Optional. >>>> >>> >>> I was expecting the common usage of StackWalker API does not need file name >>> and line number. I think it'd be useful to include StackFrame::getBci (in >>> the future it might include live information like locals etc) and keep the >>> optional stuff and uncommon usage to StackTraceElement. >>> >>> Mandy >>> >>> >>>> Rémi >>>> >>>> >>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung <mandy.ch...@oracle.com> a >>>> écrit : >>>>> 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 >>>> >>> >>> >> >> > >
