What I remember from email interactions that Ralph had with the people working on the Stackwalker implementation:
Ostensibly Stackwalker was supposed to give performance benefits for use cases like ours. They even mentioned discovering the location of a logging call as one of the main use cases. They suggested a certain way of using the stackwalker API that gave very good performance. (I believe walking from the top down.) Then, when Ralph pointed out that this usage didn’t meet our requirements because of potential recursion (the actual first call into the logging framework may be a few frames deeper), they kind of ignored that and just continued with their previous plan. So we ended up with a stackwalker API that is designed for a different use case than ours and doesn’t help us much. Ralph, does that match your memories of what happened? Remko (Shameless plug) Every java main() method deserves http://picocli.info > On Aug 9, 2018, at 0:35, Matt Sicker <boa...@gmail.com> wrote: > > StackWalker seems to be implemented purely as it says: walking the call > stack. If all you need is the stack of classes (e.g., for checking runtime > permissions based on the calling class), then the SecurityManager makes > most sense since it seems built for that exact purpose. I'd imagine there > are optimizations in place considering how often that class stack is > checked at runtime by just the JDK. > >> On Tue, 7 Aug 2018 at 22:10, Carter Kozak <c4kof...@gmail.com> wrote: >> >> My guess is that StackWalker provides additional information beyond >> the array of classes >> supplied by the SecurityManager, though I've not done a thorough analysis >> yet. >> >> A quick targeted benchmark of our current implementations: >> >> Benchmark Mode Cnt >> Score Error Units >> StackTraceBenchmark.defaultJava8 thrpt 3 113965.921 ± >> 119706.986 ops/s >> StackTraceBenchmark.securityManager thrpt 3 788004.237 ± 82578.567 >> ops/s >> StackTraceBenchmark.stackWalker thrpt 3 182902.031 ± >> 39018.395 ops/s >> >> >> -ck >> >> On Tue, Aug 7, 2018 at 7:20 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>> I have to wonder why using the security manager is faster than using >> StackWalker. StackWalker was created just for this purpose. Is the way it >> is implemented the problem? >>> >>> Ralph >>> >>> >>>> On Aug 7, 2018, at 1:34 PM, cakofony <g...@git.apache.org> wrote: >>>> >>>> GitHub user cakofony opened a pull request: >>>> >>>> https://github.com/apache/logging-log4j2/pull/202 >>>> >>>> [LOG4J2-2391] Improve ThrowableProxy performace on java 9+ >>>> >>>> Share the SecurityManager implementation of getCurrentStackTrace >>>> with the java 9 implementation. >>>> >>>> You can merge this pull request into a Git repository by running: >>>> >>>> $ git pull https://github.com/cakofony/logging-log4j2 >> java9_getcurrentstacktrace >>>> >>>> Alternatively you can review and apply these changes as the patch at: >>>> >>>> https://github.com/apache/logging-log4j2/pull/202.patch >>>> >>>> To close this pull request, make a commit to your master/trunk branch >>>> with (at least) the following in the commit message: >>>> >>>> This closes #202 >>>> >>>> ---- >>>> commit 52bf8569e8e9881d0999156c31d99b99f28e6e73 >>>> Author: Carter Kozak <ckozak@...> >>>> Date: 2018-08-07T20:27:10Z >>>> >>>> [LOG4J2-2391] Improve ThrowableProxy performace on java 9+ >>>> >>>> Share the SecurityManager implementation of getCurrentStackTrace >>>> with the java 9 implementation. >>>> >>>> ---- >>>> >>>> >>>> --- >>>> >>> >>> >> > > > -- > Matt Sicker <boa...@gmail.com>
