New date & time formatter is not garbage free

[deepblueli]

Hi,

I am running log4j2 in garbage free mode: https://logging.apache.org/log4j/2.x/manual/garbagefree.html
However, after upgraded to latest 2.25.4, I see garbage created by log4j that's not seen before, seems to be due to new date time formatter.
After I added system property -Dlog4j2.instantFormatter=legacy then it goes away.

If garbage is expected in new date time formatter, I would suggest to update garbagefree manual page to include this setting to use legacy date time formatter.

Thanks.

[ppkarwasz]

Hi @deepblueli,

Thank you for the question.

The formatter for the %d pattern has never been entirely garbage-free, since the underlying date formatters aren't. It's true that the new formatter based on DateTimeFormatter does introduce slightly more temporary object allocation, but this behavior is intentional and documented, not in the general "Garbage-free logging" page (which mostly lists settings that influence garbage collection), but in the dedicated garbage-free section of Pattern Layout.

The main differences introduced in 2.25.0 are:

• Previously, depending on the pattern you specified, Log4j Core would use either FixedDateFormat, which generates temporary objects only once a day, or FastDateFormat, which generates temporary objects continuously.
• The current formatter generates temporary objects once per minute (14,400 times a day), but is garbage-free within that interval.

The one-minute interval was chosen to strike a balance between the frequency of temporary object allocation and the complexity of handling daylight saving time transitions: we support all time zones, including those with offsets expressed as multiples of 15 minutes.

If you are seeing temporary object allocation more frequently than once per minute, please open an issue and help debug the problem if possible.

Otherwise, if the allocation frequency is not acceptable for your use case, there are two ways to improve it:

• Contribute code that reduces how often the "constant" part of the date is recomputed: for example, to once per hour when the timezone offset is a multiple of an hour.
• Propose a configuration property that allows users to opt in to a lower recomputation frequency, for cases where daylight saving transitions or non-hour UTC offsets are not a concern.