[
https://issues.apache.org/jira/browse/LOG4J2-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158421#comment-15158421
]
Remko Popma edited comment on LOG4J2-1295 at 2/23/16 7:03 AM:
--------------------------------------------------------------
A quick survey (there may be other options):
*Reflection on ThreadMXBean*
A simple approach is to use
[ThreadMXBean.getThreadAllocatedBytes|https://docs.oracle.com/javase/7/docs/api/java/lang/management/ThreadMXBean.html]
before and after a test and verify the number did not increase. This does not
point to the place in the code that does the allocation but is easy to
implement and does not require an agent. (Reflection because this is in the
com.sun.management package, not java.lang.management. JMH does
[this|http://mail.openjdk.java.net/pipermail/jmh-dev/2015-April/001801.html]).
*AspectJ*
The nice thing about aspects is that this can throw an exception when an object
is allocated, which pinpoints directly to the place where the code needs fixing.
It will take (me) some time to learn how AspectJ works. I do know that it needs
to run with a java agent, so it may take some work to package this in a JUnit
test.
*Allocation Instrumenter*
This is an open source project (java agent) written for the purpose of
detecting allocation and giving a callback when allocation occurred:
https://github.com/google/allocation-instrumenter
*HPROF*
Finally, perhaps we can use
[hprof|http://www.oracle.com/technetwork/java/javase/tooldescr-136044.html#gbluz]
was (Author: [email protected]):
A quick survey (there may be other options):
*Reflection on ThreadMXBean*
A simple approach is to use
[ThreadMXBean.getThreadAllocatedBytes|https://docs.oracle.com/javase/7/docs/api/java/lang/management/ThreadMXBean.html]
before and after a test and verify the number did not increase. This does not
point to the place in the code that does the allocation but is easy to
implement and does not require an agent. (Reflection because this is in the
com.sun.management package, not java.lang.management).
*AspectJ*
The nice thing about aspects is that this can throw an exception when an object
is allocated, which pinpoints directly to the place where the code needs fixing.
It will take (me) some time to learn how AspectJ works. I do know that it needs
to run with a java agent, so it may take some work to package this in a JUnit
test.
*Allocation Instrumenter*
This is an open source project (java agent) written for the purpose of
detecting allocation and giving a callback when allocation occurred:
https://github.com/google/allocation-instrumenter
*HPROF*
Finally, perhaps we can use
[hprof|http://www.oracle.com/technetwork/java/javase/tooldescr-136044.html#gbluz]
> Automated testing to verify no temporary objects allocated in gc-free
> configuration
> -----------------------------------------------------------------------------------
>
> Key: LOG4J2-1295
> URL: https://issues.apache.org/jira/browse/LOG4J2-1295
> Project: Log4j 2
> Issue Type: New Feature
> Components: API, Configurators, Core, Layouts, Pattern Converters
> Affects Versions: 2.5
> Reporter: Remko Popma
>
> LOG4J2-1270 proposes changes to support gc-free behaviour (no allocation of
> temporary objects) in certain configurations.
> This ticket is about verifying that Log4j does not allocate in these
> configurations. It is not always obvious that some code creates objects, so
> it is easy for regressions to creep in during maintenance code changes.
> Ideally this verification is packaged so it can run automatically during the
> test phase of the build, for example in a JUnit test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
