Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Mandy Chung mandy.chung at oracle.com
Wed Apr 13 17:27:52 UTC 2016


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.goers at 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.chung at oracle.com> wrote:
>> 
>> 
>>> On Apr 12, 2016, at 1:34 AM, Rémi Forax <forax at 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.chung at 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
>>> 
>> 
>> 
> 
> 




More information about the core-libs-dev mailing list