Yup. Part of the problem is that StackWalker is optimized for only walking a few frames. I think it caches 8 stack frames. After that it apparently slows down a lot. I don’t recall there being any way to tune that.
Ralph > On Aug 8, 2018, at 5:07 PM, Remko Popma <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >
