I have fixed the test that located the caller’s Class object with StackWalker. It is now faster than Reflection.getCallerClass() was.
I have also created a test to get the Caller’s StackTraceElement with StackWalker. It is now much, much faster than walking the Throwable was in Java 8, so that will be a definite incentive for Log4j to use it. Sorry for the misinformation on these but thanks for giving me help on improving the tests. Ralph > On Mar 13, 2017, at 3:38 PM, Mandy Chung <[email protected]> wrote: > > Hi Ralph, > > I have filed https://bugs.openjdk.java.net/browse/JDK-8176593 > <https://bugs.openjdk.java.net/browse/JDK-8176593> for > Throwable::getStackTrace performance regression. > >> On Mar 13, 2017, at 1:57 PM, Daniel Fuchs <[email protected]> wrote: >> >> Hi Ralph, >> >> On 13/03/17 19:06, Ralph Goers wrote: >>> OK - I will do that when I fix the other bug. But if you can suggest some >>> other way to bail out of the loop after I have found the correct StackFrame >>> that would help as well. >>> >> >> I'd suggest using filter + findFirst, possibly with a >> statefull Predicate<StackFrame> - depending on the logic >> needed to identify the frame you want to return. >> >> >> That's what we do in java.util.logging - where we walk >> until we find a logger implementation frame, and then >> continue walking until we find a frame that no longer >> belong to the logging infrastructure. > > As Daniel said, we suggest to walk the stack from the most recent frame and > stops when the logging implementation frames are skipped. > > This is where java.util.logging does its filtering that you can reference: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/ddf8af0e536a/src/java.logging/share/classes/java/util/logging/LogRecord.java#l696 > > <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/ddf8af0e536a/src/java.logging/share/classes/java/util/logging/LogRecord.java#l696> > > Mandy
