[ 
https://issues.apache.org/jira/browse/LOG4J2-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172963#comment-15172963
 ] 

Matt Sicker commented on LOG4J2-1295:
-------------------------------------

One little bit of help you have here is that I've started annotating certain 
areas with {{@PerformanceSensitive("allocation")}} to indicate that no new 
objects should be created by this method. This could be used to at least verify 
that a GC test was performed on all these methods or maybe some other ingenious 
idea (like generating random data to invoke the method). Though you may need to 
make the annotation retained at runtime so you can reflect on it (unnecessary 
in an annotation processor, however).

> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to