Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed
mandy.chung at oracle.com
Mon Mar 13 15:56:53 UTC 2017
> On Mar 12, 2017, at 9:25 PM, Ralph Goers <ralph.goers at dslextreme.com> wrote:
> Sorry for not getting back sooner but I finally found some time to follow up.
> I took a look at https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/ <https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/> and modified the benchmarks that were used there to add a few more use cases. I also created a small set of benchmarks for Java 8 to compare it against. The resulting project is at https://github.com/rgoers/stackwalker-vs-Reflection_getCallerClass/tree/master/java9 <https://github.com/rgoers/stackwalker-vs-Reflection_getCallerClass/tree/master/java9>. I’ve summarized the results in https://issues.apache.org/jira/browse/LOG4J2-1359 <https://issues.apache.org/jira/browse/LOG4J2-1359>, but for your convenience here are the bullet points:
> 1. Walking the Throwable StackTraceElements is significantly faster in Java 8 than Java 9. I am not sure what benchmark Brent used but my results differ.
I’ll be surprised if jdk 9 Throwable is slower than jdk 8 as JDK-8150778 should give some improvement.
We will look into it.
> 2. Using StackWalker to get the StackTraceElements in Java 9 is almost twice as slow as walking the Throwable in Java 8. (Log4j relied on this pre-Java9 and apparently will have to continue to do so, but it will now be slower).
> 3. Using StackWalker to search for the caller's class is about twice as slow as sun.reflect.Reflection.getCallerClass() was (Log4j requires this and it is going to hurt performance).
This of course needs to look at the difference between our benchmarks and yours and understands show the perf gap. There is of course room for performance tuning.
> 4. sun.reflect.Reflection.getCallerClass is about 10 times faster than using StackWalker.getCallerClass to obtain the Class object of the immediate caller.
Does Log4J look at the immediate caller? AFAIU, the libraries are depending sun.reflect.Reflection.getCallerClass(int). One use case of logging is to filter the logging implementation frames and find the first caller after filtering several frames. We have tuned the performance for such use case. For getting the immediate caller, we expect most existing code using Reflection::getCallerClass will call StalkWalker::walk but not getCallerClass(). It’s slower but I’m surprised of this number.
More information about the core-libs-dev