Is the Garbage-free mode enabled by default?

[lushi516]

I reviewed the garbagefree documentation, and it states that the Garbage-free mode requires additional configuration and activation. However, when I tested the logback-perf code, I noticed that even with the default configuration and extensive logging output, it did not trigger any GC (Garbage Collection).

perf result

Benchmark                                                           Mode  Cnt    Score   Error   Units
AsyncWithFileAppenderBenchmark.log4j2AsyncFile                     thrpt    2  170.888          ops/ms
AsyncWithFileAppenderBenchmark.log4j2AsyncFile:gc.alloc.rate       thrpt    2   ≈ 10??          MB/sec
AsyncWithFileAppenderBenchmark.log4j2AsyncFile:gc.alloc.rate.norm  thrpt    2    0.002            B/op
AsyncWithFileAppenderBenchmark.log4j2AsyncFile:gc.count            thrpt    2      ≈ 0          counts
AsyncWithFileAppenderBenchmark.logbackFile                         thrpt    2  209.157          ops/ms
AsyncWithFileAppenderBenchmark.logbackFile:gc.alloc.rate           thrpt    2  181.193          MB/sec
AsyncWithFileAppenderBenchmark.logbackFile:gc.alloc.rate.norm      thrpt    2  908.393            B/op
AsyncWithFileAppenderBenchmark.logbackFile:gc.count                thrpt    2   36.000          counts
AsyncWithFileAppenderBenchmark.logbackFile:gc.time                 thrpt    2   44.000              ms
FileAppenderBenchmark.log4j2File                                   thrpt    2  126.649          ops/ms
FileAppenderBenchmark.log4j2File:gc.alloc.rate                     thrpt    2   ≈ 10??          MB/sec
FileAppenderBenchmark.log4j2File:gc.alloc.rate.norm                thrpt    2    0.003            B/op
FileAppenderBenchmark.log4j2File:gc.count                          thrpt    2      ≈ 0          counts
FileAppenderBenchmark.logbackFile                                  thrpt    2  121.266          ops/ms
FileAppenderBenchmark.logbackFile:gc.alloc.rate                    thrpt    2   94.102          MB/sec
FileAppenderBenchmark.logbackFile:gc.alloc.rate.norm               thrpt    2  813.717            B/op
FileAppenderBenchmark.logbackFile:gc.count                         thrpt    2   19.000          counts
FileAppenderBenchmark.logbackFile:gc.time                          thrpt    2   26.000              ms

Is the Garbage-free mode activated by default? Is it possible to inspect through Log4j2's own logs?

PS:

（1） jdk and log4j2 verison is 1.8.171 and 2.24.3

（2）log4j2.xml

<Configuration name="log4j2PerfTest" status="trace">

	<Appenders>

		<File name="RandomAccessFile"
			fileName="target/test-output/log4j2-perf.log" immediateFlush="false"
			append="false" bufferSize="262144">
			<PatternLayout>
				<Pattern>%d %p [%t] %logger - %m%n</Pattern>
			</PatternLayout>
		</File>


	</Appenders>

	<Loggers>
		<Root level="debug">
			<AppenderRef ref="RandomAccessFile" />
		</Root>
	</Loggers>
</Configuration>

[ppkarwasz]

Is the Garbage-free mode activated by default?

This depends on the Java application environment (see meta configuration properties). By default:

• if the Java EE or Jakarta EE Servlet class is present, log4j2.isWebapp has value true and log4j2.enableThreadlocals has value false: GC-mode is disabled.
• Otherwise log4j2.isWebapp has value false and log4j2.enableThreadlocals has value true: GC-mode is enabled.

In your case GC-mode is probably on.

Is it possible to inspect through Log4j2's own logs?

I don't believe we log that information.

[lushi516]

thinks ,but

ThreadLocal fields holding non-JDK classes can cause memory leaks in web applications when the application server’s thread pool continues to reference these fields after the web application is undeployed. Hence, to avoid causing memory leaks, log4j2.enableThreadlocals by default reflects the opposite of log4j2.isWebapp.

According to the document above, I understand that if a web application enables Garbage-free mode, it may cause a memory overflow?
If so, then web programs, in most cases, should not be in Garbage-free mode, unless it can be clearly used are all built-in classes of JDK.

[ppkarwasz]

ThreadLocal fields holding non-JDK classes can cause memory leaks in web applications when the application server’s thread pool continues to reference these fields after the web application is undeployed. Hence, to avoid causing memory leaks, log4j2.enableThreadlocals by default reflects the opposite of log4j2.isWebapp.

According to the document above, I understand that if a web application enables Garbage-free mode, it may cause a memory overflow? If so, then web programs, in most cases, should not be in Garbage-free mode, unless it can be clearly used are all built-in classes of JDK.

If log4j2.enableThreadlocals is enabled and Log4j Core is contained in the web application classloader, you will experience memory leaks each time you restart the application. Basically the memory retained by the stopped web application classloader will not be reclaimed by the GC. IIRC, ThreadLocals that only store JDK classes are enabled regardless of the log4j2.enableThreadlocals setting (e.g. the buffers enabled by log4j2.enableDirectEncoders).

Note: even in Servlet applications, you can safely enable log4j2.enableThreadlocals, if:

• You share Log4j Core between applications. See Sharing Log4j Core between Web Applications.
• You have a single web application in your application server. For example, Spring Boot web applications can use a Servlet container under the hood. However, since you restart the whole JVM each time you want to restart the web application, you can safely enable log4j2.enableThreadlocals.

[youngledo]

@ppkarwasz Hello, should we recommend enabling "log4j2.enableThreadlocals" in Spring Boot? I checked the Spring Boot official website and it seems they haven't done this.

link:

• https://docs.spring.io/spring-boot/docs/3.0.13/reference/html/features.html#features.logging.log4j2-extensions.environment-property-source
• When using embedded servlets and log4j2, should "log4j2.enableThreadlocals" be enabled by default to avoid GC issues? spring-projects/spring-boot#47137 (comment)

[ppkarwasz]

Spring Boot applications can be deployed both using an external and embedded Servlet container, so there is no good default to propose.

The current default (true unless the Servlet API is present) is a rather safe default, since it limits the risk of memory leaks, which are more important than performance.

[jvz]

It might help to consider that production applications which rely on garbage-free Java usage tend to only run for like 8 hours a day or so and can be rebooted afterwards. The point of garbage-free options are to have predictable memory usage at the cost of using more memory.