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 >>> >> >> > >
