[
https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133078#comment-14133078
]
Gary Gregory edited comment on LOG4J2-819 at 9/14/14 4:47 AM:
--------------------------------------------------------------
To answer my own question it looks like {{nanoTime}} is _more_ expensive than
{{currentTimeMillis}}. Am I reading this right?
{noformat}
# Run complete. Total time: 00:01:38
Benchmark Mode Samples
Mean Mean error Units
o.a.l.l.p.j.ClocksBenchmark.baseline sample 60088
13.435 0.952 ns/op
o.a.l.l.p.j.ClocksBenchmark.cachedClock sample 83142
29.188 1.191 ns/op
o.a.l.l.p.j.ClocksBenchmark.coarseCachedClock sample 46747
13.653 1.166 ns/op
o.a.l.l.p.j.ClocksBenchmark.fixedClock sample 92588
16.373 1.043 ns/op
o.a.l.l.p.j.ClocksBenchmark.fixedFinalClock sample 93548
14.057 0.803 ns/op
o.a.l.l.p.j.ClocksBenchmark.systemClock sample 70663
29.297 2.336 ns/op
o.a.l.l.p.j.ClocksBenchmark.systemCurrentTimeMillis sample 78074
25.457 1.127 ns/op
o.a.l.l.p.j.ClocksBenchmark.systemNanoTime sample 88921
35.775 1.519 ns/op
{noformat}
I added {{systemNanoTime}} locally and did not commit.
was (Author: garydgregory):
To answer my own question it looks like {{nanoTime}} is _more_ expensive than
{{currentTimeMillis}}:
{noformat}
# Run complete. Total time: 00:01:38
Benchmark Mode Samples
Mean Mean error Units
o.a.l.l.p.j.ClocksBenchmark.baseline sample 60088
13.435 0.952 ns/op
o.a.l.l.p.j.ClocksBenchmark.cachedClock sample 83142
29.188 1.191 ns/op
o.a.l.l.p.j.ClocksBenchmark.coarseCachedClock sample 46747
13.653 1.166 ns/op
o.a.l.l.p.j.ClocksBenchmark.fixedClock sample 92588
16.373 1.043 ns/op
o.a.l.l.p.j.ClocksBenchmark.fixedFinalClock sample 93548
14.057 0.803 ns/op
o.a.l.l.p.j.ClocksBenchmark.systemClock sample 70663
29.297 2.336 ns/op
o.a.l.l.p.j.ClocksBenchmark.systemCurrentTimeMillis sample 78074
25.457 1.127 ns/op
o.a.l.l.p.j.ClocksBenchmark.systemNanoTime sample 88921
35.775 1.519 ns/op
{noformat}
I added {{systemNanoTime}} locally and did not commit.
> PermGen OutOfMemoryError when reloading webapp on Tomcat 6
> ----------------------------------------------------------
>
> Key: LOG4J2-819
> URL: https://issues.apache.org/jira/browse/LOG4J2-819
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.2
> Environment: Tomcat 6
> Reporter: Costa Theodosiou
> Priority: Critical
> Attachments: demo.zip, demorun-tomcat6-with-reload.zip, demorun.zip,
> gg-log4j2-clocks-interrupts.patch, gg-log4j2-clocks-v2.patch
>
>
> When reloading an application 3 or 4 times in Tomcat 6, the application
> crashes with a "java.lang.OutOfMemoryError: PermGen space" exception.
> After some investigation using the "When all else fails" section of
> https://wiki.apache.org/tomcat/OutOfMemory in conjunction with Java VisualVM,
> I have narrowed down the problem to the Thread created within
> org.apache.logging.log4j.core.util.CoarseCachedClock.
> When a Thread is created, it contains a reference to the classloader that it
> was created with. In this case, the Thread's contextClassLoader field
> contains a reference to the WebappClassLoader. When Tomcat attempts to unload
> the webapp, the Thread still holds onto this reference which prevents
> WebappClassLoader from being freed.
> Perhaps the Log4jServletContextListener (Log4jWebInitializerImpl) can be made
> to stop the CoarseCachedClock thread.
> I believe this is not an obvious issue on Tomcat 7 due to
> https://wiki.apache.org/tomcat/MemoryLeakProtection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
