[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953023#comment-15953023 ] ASF subversion and git services commented on LOG4J2-1359: - Commit 34552d7d725c3b7547e1c19f6ce803b83c60bd94 in logging-log4j2's branch refs/heads/java9NoMultiRelease from [~ralph_go...@dslextreme.com] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=34552d7 ] LOG4J2-1359 - Set up for modules. Do not use multi-release jars > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931946#comment-15931946 ] Ralph Goers commented on LOG4J2-1359: - In the issue for the Maven bundle plugin it was suggested we use a "service" for the replaceable functionality, which I take to mean that the ServiceLoader should be used. I'll have to dwell on the issues in doing that. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931936#comment-15931936
]
Ralph Goers commented on LOG4J2-1359:
-
Here are the results of the benchmarks. Overall, it seems that most of the
tests are a bit slower in Java 9. Serializing an Event that has an Exception is
a LOT slower, which is probably a result of the performance regression I
already reported. However, getting the location information takes about 1/3 the
time it did in Java 7.
I don't understand the results of the serialization tests though. Although it
is understandable that building a log event without an exception would be much
faster than building one without one, I would have expected that building a
serialized log event with location information would be about the same as
building an event without location information + the time to get the location
information. Instead, in Java 9 it is showing as slightly faster than getting
the event without location information. I am thinking there must be something
wrong with the test.
Java 7
{code}
Benchmark
Mode Samples Score Error Units
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithExceptionUsingBuilder
avgt5147.173 ±3.876 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutException
avgt5177.807 ± 18.619 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutExceptionUsingBuilder
avgt5146.371 ±9.554 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithException
avgt5 18450.541 ± 380.800 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutException
avgt5250.715 ±8.624 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutExceptionWithLocation
avgt5274.293 ± 35.927 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.getSourceLocationOfLogEvent
avgt5 19988.446 ± 1752.194 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.testBaseline
avgt5 0.391 ±0.028 ns/op
{code}
Java 9
{code}
Benchmark
Mode Samples Score Error Units
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithExceptionUsingBuilder
avgt5190.018 ± 28.264 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutException
avgt5228.393 ± 16.702 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutExceptionUsingBuilder
avgt5171.760 ± 26.799 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithException
avgt5 32257.972 ± 4868.261 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutException
avgt5285.204 ± 20.197 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutExceptionWithLocation
avgt5271.399 ± 28.883 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.getSourceLocationOfLogEvent
avgt5 6839.420 ± 1007.405 ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.testBaseline
avgt5 0.402 ±0.009 ns/op
{code}
> Add support for Java 9 StackWalker API in ReflectionUtil
>
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
> Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require
> compiling at least one class using javac 1.9 and reflectively loading it in
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a
> slower API in Java 1.9. This is because the Reflection class is a
> sun-internal class which are no longer exported to non-JDK code without
> setting special command line flags.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail:
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931937#comment-15931937 ] ASF subversion and git services commented on LOG4J2-1359: - Commit 311101cb47594a4bc781a5365a471d5be7f40647 in logging-log4j2's branch refs/heads/LOG4J2-1359 from [~ralph_go...@dslextreme.com] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=311101c ] LOG4J2-1359 - Remove print statement > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931900#comment-15931900 ] ASF subversion and git services commented on LOG4J2-1359: - Commit 8eac91024cce617b15838c1f630d8aa32703c6f3 in logging-log4j2's branch refs/heads/LOG4J2-1359 from [~ralph_go...@dslextreme.com] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=8eac910 ] LOG4J2-1359 - Benchmark impact on LogEvent > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931455#comment-15931455 ] Ralph Goers commented on LOG4J2-1359: - I have created branch LOG4J2-1359. To build Log4j you must install Java 9 and create a toolchains.xml that points to it. I have created a Jenkins job that verifies the build works in Jenkins (obviously). The only thing I don't like is that the toolchains.xml file has to be updated to point to the latest java 9 install. For some reason there is no symlink. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931412#comment-15931412 ] ASF subversion and git services commented on LOG4J2-1359: - Commit e6ce8e4e137f00e9c3ab2f341dfda03c1f76a88a in logging-log4j2's branch refs/heads/LOG4J2-1359 from [~ralph_go...@dslextreme.com] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=e6ce8e4 ] LOG4J2-1359 - Ignore javadoc problems in core due to Java 9 classes. Modify build instructions > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931396#comment-15931396 ] ASF subversion and git services commented on LOG4J2-1359: - Commit 4e44466fddb33da1835d82f44a538277741b9156 in logging-log4j2's branch refs/heads/LOG4J2-1359 from [~ralph_go...@dslextreme.com] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=4e44466 ] LOG4J2-1359 - Remove profiles > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931099#comment-15931099 ] ASF subversion and git services commented on LOG4J2-1359: - Commit 0854d32523cc2f244a0ed9a927154dadfbf9534e in logging-log4j2's branch refs/heads/LOG4J2-1359 from [~ralph_go...@dslextreme.com] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=0854d32 ] LOG4J2-1359 - Java 9 support > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924922#comment-15924922 ] Ralph Goers commented on LOG4J2-1359: - It would be a direct replacement for the method in ReflectionUtil and calcLocation in Log4jLogEvent. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924455#comment-15924455 ] Matt Sicker commented on LOG4J2-1359: - Is this performance gain only feasible by directly using the StackWalker API in, for example, LogManager and ClassLoaderContextSelector, or does it still perform well when wrapped by ReflectionUtil (and thus requiring an additional stack frame)? If it's the former, then we're going to end up with several classes with Java 9 specific versions in the multi-jar. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15923621#comment-15923621
]
Ralph Goers commented on LOG4J2-1359:
-
I have modified the test that locates the caller class and added a test to
locate the caller's StackTraceElement using StackWalker using the same
algorithm Log4j uses. The performance of locating the caller's Class is greatly
improved from the numbers above and is now faster than using
Reflection.getCallerClass(). Locating the caller's StackTraceElement is also
much faster with StackWalker than walking the Throwable.
I should point out that I tried various methods to locate the caller's class
and StackTraceElement and finally settled on using the filter method as
dropWhile() and reduce() were much slower.
{code}
Benchmark (limit)
(skip) Mode Cnt Score Error Units
StackWalkerGetCallerClass.securityManager N/A
N/A avgt 20 1.478 ± 0.013 us/op
StackWalkerGetCallerClass.stackwalkerGetImmediate N/A
N/A avgt 20 1.185 ± 0.012 us/op
StackWalkerGetCallerClass.stackwalkerSearchN/A
N/A avgt 20 2.335 ± 0.017 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 1
N/A avgt 20 2.397 ± 0.043 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 2
N/A avgt 20 2.424 ± 0.027 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 4
N/A avgt 20 2.757 ± 0.028 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 6
N/A avgt 20 3.045 ± 0.031 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 8
N/A avgt 20 7.804 ± 0.247 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit10
N/A avgt 20 7.711 ± 0.062 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit12
N/A avgt 20 7.984 ± 0.038 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit14
N/A avgt 20 8.537 ± 0.342 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit16
N/A avgt 20 13.232 ± 0.142 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit1
N/A avgt 20 2.640 ± 0.049 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit2
N/A avgt 20 2.514 ± 0.014 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit4
N/A avgt 20 2.749 ± 0.179 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit6
N/A avgt 20 2.627 ± 0.015 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit8
N/A avgt 20 3.368 ± 0.028 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit 10
N/A avgt 20 4.156 ± 0.033 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit 12
N/A avgt 20 4.857 ± 0.093 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit 14
N/A avgt 20 5.461 ± 0.065 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit 16
N/A avgt 20 6.104 ± 0.088 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
1 avgt 20 12.613 ± 0.046 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
2 avgt 20 12.705 ± 0.156 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
4 avgt 20 12.484 ± 0.173 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
6 avgt 20 12.275 ± 0.063 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
8 avgt 20 12.552 ± 0.175 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
10 avgt 20 12.349 ± 0.167 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
12 avgt 20 12.564 ± 0.153 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
14 avgt 20 13.128 ± 0.476 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
16 avgt 20 13.246 ± 0.532 us/op
StackWalkerVsExceptionBenchmark.exceptionStackTraceN/A
N/A avgt 20 28.558 ± 0.343 us/op
StackWalkerVsExceptionBenchmark.stackWalkerForEach N/A
N/A avgt 20 12.873 ± 0.171 us/op
StackWalkerVsExceptionBenchmark.stackWalkerForEachRetainClass N/A
N/A avgt 20 12.828
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15923236#comment-15923236 ] Ralph Goers commented on LOG4J2-1359: - https://bugs.openjdk.java.net/browse/JDK-8176593 has been created for the performance issue with Throwable. I am working on the search performance test as the current method is forced to consume the whole stack. Also, it was recommended to move the creation of the StackWalker out of the test. There was at least one place where this was done in the original tests and I will fix it there as well. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15922740#comment-15922740 ] Mandy Chung commented on LOG4J2-1359: - See http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046682.html Are these benchmarks taking entire stack? StackWalker API improves the performance of the use case when you walk the stack from the most recent execution frame and stops when you reach a certain frame. Also the use case when you want to look at the frame information such as classname/method name or Class object. There is cost to get StackTraceElement is high that could be improved. The important thing is to replace the calls to sun.reflect.Reflection.getCallerClass(int) with StackWalker::walk. I would suggest to experiment doing the stack walk from the most recent frame and determine any performance improvement. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15907673#comment-15907673 ] Ralph Goers commented on LOG4J2-1359: - Yes, I posted to the open jdk list and referenced this Jira issue and pointed them to my benchmark project. I have not heard anything yet. Of course, it could be possible that there is something wrong with the benchmark code. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15907500#comment-15907500 ] Matt Sicker commented on LOG4J2-1359: - Well that's no good! Have you posted this to the jdk mailing lists, too? In order to access sun.reflect in Java 9, I think we'll have to add some compilation flags as they're trying to hide all their internal APIs that have public equivalents. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906837#comment-15906837
]
Ralph Goers commented on LOG4J2-1359:
-
I have copied the benchmarks from the sitepoint article and modified them
slightly and added benchmarks for java 8. The project is at
https://github.com/rgoers/stackwalker-vs-Reflection_getCallerClass. The results
on my machine are below. The take-aways are:
1. Walking the Throwable StackTraceElements is significantly faster in Java 8
than Java 9, so my memory is correct.
2. Using StackWalker to get the StackTraceElements is almost twice as slow as
walking the Throwable in Java 8.
3. Using StackWalker to search for the caller's class is about twice as slow as
sun.reflect.Reflection.getCallerClass() was.
4. sun.reflect.Reflection.getCallerClass is about 10 times faster than using
StackWalker.getCallerClass to obtain the Class object of the immediate caller.
In short it appears that the performance of StackWalker means that we are going
to want to avoid using it.
Java 8:
{code}
BenchmarkMode Cnt Score Error
Units
ExceptionBenchmark.exceptionStackTrace avgt 20 19.796 ± 0.405
us/op
StackWalkerGetCallerClass.exceptionGetImmediate avgt 20 0.135 ± 0.002
us/op
StackWalkerGetCallerClass.reflectionSearch avgt 20 3.844 ± 0.057
us/op
StackWalkerGetCallerClass.securityManageravgt 20 0.949 ± 0.013
us/op
{code}
Java 9:
{code}
Benchmark (limit)
(skip) Mode Cnt Score Error Units
StackWalkerGetCallerClass.securityManager N/A
N/A avgt 20 1.498 ± 0.014 us/op
StackWalkerGetCallerClass.stackwalkerGetImmediate N/A
N/A avgt 20 1.124 ± 0.009 us/op
StackWalkerGetCallerClass.stackwalkerSearchN/A
N/A avgt 20 7.083 ± 0.723 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 1
N/A avgt 20 2.640 ± 0.318 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 2
N/A avgt 20 2.635 ± 0.214 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 4
N/A avgt 20 2.779 ± 0.284 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 6
N/A avgt 20 3.051 ± 0.274 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 8
N/A avgt 20 7.555 ± 0.902 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit10
N/A avgt 20 7.824 ± 0.965 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit12
N/A avgt 20 12.369 ± 6.191 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit14
N/A avgt 20 8.861 ± 2.315 us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit16
N/A avgt 20 13.643 ± 1.141 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit1
N/A avgt 20 2.754 ± 0.367 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit2
N/A avgt 20 2.669 ± 0.386 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit4
N/A avgt 20 2.722 ± 0.274 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit6
N/A avgt 20 2.812 ± 0.222 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit8
N/A avgt 20 3.555 ± 0.532 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit 10
N/A avgt 20 4.259 ± 0.493 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit 12
N/A avgt 20 6.149 ± 5.423 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit 14
N/A avgt 20 5.707 ± 0.629 us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit 16
N/A avgt 20 6.336 ± 0.928 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
1 avgt 20 13.079 ± 0.991 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
2 avgt 20 13.321 ± 1.130 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
4 avgt 20 13.379 ± 1.243 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
6 avgt 20 13.054 ± 1.193 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
8 avgt 20 13.041 ± 0.764 us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A
10 avgt 20 13.359 ± 0.659 us/op
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906252#comment-15906252 ] Ralph Goers commented on LOG4J2-1359: - Let's see if I can help. First, I suggest you read https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/. Notice that when StackWalker::forEach is used to get the StackTraceElement containing the file name and line number it is actually slower than walking the Throwable, which is in contrast to Reflection.getCallerClass() where we get a performance boost. But also notice that the cost decreases with the number of stack frames that have to be retrieved. So the openjdk devs recommend using StackWalker's getCallerClass method. Of course, the only way to do that is to have the call be in the first Log4j method that is called. Then we would have to pass the retrieved StackFrame instead of the FQCN. IOW, we would not lazily resolve the location information. I have my doubts that can be done without unacceptable performance consequences. Worse, I did some gross testing and it seemed that walking the Throwable was slower in Java 9 than in Java 8. However, the openjdk devs believe I did something wrong. The only way to know is to test it. I plan to do just that by starting with https://github.com/pingtimeout/stack-walker-benchmark and then creating a Java 8 version and a Java 9 version. So yes, we can defer walking the stack but the cost of retrieving location information will probably be worse than it is pre-Java 9. For a reference to the core-libs discussion see the thread that starts with http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040826.html. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906209#comment-15906209 ] Remko Popma commented on LOG4J2-1359: - Is it possible to compile only one class with Java 9 and the rest with Java 7? We currently delay walking the stack until we need to. Can we do something similar with capturing the stack? That is, only capture it when a) we're logging synchronously and one of the pattern converters asks for the caller location, or b) we're logging asynchronously and we're configured to capture a stack snapshot before handing over the log event details to the background thread? I don't understand what the openjdk devs are suggesting concretely. Can you point me to something (a specific API, or an example, or an email) that would clarify? > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906196#comment-15906196 ] Ralph Goers commented on LOG4J2-1359: - I need to get back to this... Java 9 provides multi-version support - we can provide one version of a class for pre-java9 and another for java9, but it requires the build be done with java 9, which I am reluctant to do. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231614#comment-15231614 ] Matt Sicker commented on LOG4J2-1359: - If there's no way to mix the compile environment, then I guess it would have to be in its own jdk9 module, yeah. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231610#comment-15231610 ] Remko Popma commented on LOG4J2-1359: - Interesting. Given the need to compile this with javac 1.9, would this be a separate module then? > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231611#comment-15231611 ] Ralph Goers commented on LOG4J2-1359: - I tested StackWalker a few weeks ago. I don't remember the actual numbers I got, but StackWalker was considerably faster than using a Throwable to capture the location information. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
