What I don’t understand is that ThrowableProxy seems to be doing a whole bunch of stuff in the constructor. I would think a lot of that could be deferred until the Throwable is being rendered.
Ralph > On Aug 9, 2018, at 8:10 AM, Carter Kozak <c4kof...@gmail.com> wrote: > > The piece I'd like to avoid is ThrowableProxy.loadClass invocations, > which can be expensive depending on the ClassLoader implementation. > The ThrowablePatternConverter implementations all fall back to the > default implementation which operates directly on a Throwable rather > than the proxy object. > > I would prefer to make ThrowableProxy work better rather than > disabling it entirely, which would open the flood gates for issues > with the Jackson and Serializable layouts, though the counterargument > is that without loading classes, there is no additional information > provided by ThrowableProxy over a Throwable. > > I will take a look at flagging ThrowableProxy class loading instead of > disabling ThrowableProxy entirely when I have a moment. > > Thanks, > -ck > > On Thu, Aug 9, 2018 at 1:36 AM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: >> What is the purpose of disabling ThrowableProxy? All the throwable pattern >> converters rely on it. >> >> Ralph >> >>> On Aug 8, 2018, at 8:34 AM, Carter Kozak <cko...@apache.org> wrote: >>> >>> I'm curious what you would think of a system property to disable >>> ThrowableProxy creation? >>> My initial preference was to avoid this type of flag and make the >>> common case cleaner, however >>> without providing a mechanism to disable the functionality that >>> differentiates it from Throwable >>> I'm not sure that's feasible. >>> >>> An alternative approach may be to allow custom implementations of the >>> logic surrounding >>> ThrowableProxy.toCacheEntry which could potentially disable classloader >>> lookups, >>> or implement something like the request in github pull/195. This extension >>> point >>> would make ThrowableProxy refactors significantly more difficult in the >>> future. >>> >>> -ck >>> >>> On Tue, Aug 7, 2018 at 11:10 PM, 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. >>>>>> >>>>>> ---- >>>>>> >>>>>> >>>>>> --- >>>>>> >>>>> >>>>> >>> >> >> >
