Corneliu C created LOG4J2-1913:
----------------------------------
Summary: traceExit allocates memory for the input parameter even
if it doesn't print it
Key: LOG4J2-1913
URL: https://issues.apache.org/jira/browse/LOG4J2-1913
Project: Log4j 2
Issue Type: Improvement
Components: API
Affects Versions: 2.8.2
Reporter: Corneliu C
When calling traceExit(object instance) the underlying code allocates a Message
for the input object instance although the log level is not TRACE and there
won't be any printing in the end.
With trivial objects is not a problem but using large lists or XML objects
results in large memory allocation for nothing which goes to GC and performance
impact.
Execution flow is like this:
{code}
@Override
public <R> R traceExit(final R result) {
return exit(FQCN, null, result);
}
{code}
next _exit_ calls:
{code}
protected <R> R exit(final String fqcn, final R result) {
logIfEnabled(fqcn, Level.TRACE, EXIT_MARKER, exitMsg(null, result),
null);
return result;
}
{code}
which calls _exitMsg_ with the input parameter _result_:
{code}
protected Message exitMsg(final String format, final Object result) {
if (result == null) {
if (format == null) {
return messageFactory.newMessage("Exit");
}
return messageFactory.newMessage("Exit: " + format);
}
if (format == null) {
return messageFactory.newMessage("Exit with(" + result + ')');
}
return messageFactory.newMessage("Exit: " + format, result);
}
{code}
As it can be seen the _exitMsg()_ method is called and only later the
_logIfEnabled()_ is executed.
I assume a log level validation can be applied upfront so as _exitMsg_ is not
called for nothing.
*Note:* this is not the case for other flavors of _traceExit_ which check the
log level upfront.
Thank you
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
