[LOG4J2-3672] Avoid invoking DateFormatSymbols.getZoneStrings() in FastDateParser

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.22.0
• Assignee: Volkan Yazici
• Reporter: Tristan Tarrant
• Created: 09/Oct/23 12:32
• Updated: 02/Nov/23 17:51
• Resolved: 02/Nov/23 17:51

Description

FastDateParser uses DateFormatSymbols.getZoneStrings() to construct a table of all possible timezone names to be used in parsing date patterns in pattern layouts.

Unfortunately the above call (and the equivalent call used by the JDK's SimpleDateFormat) causes initialization and caching of all timezones, resulting in a ~3MB heap overhead on x86_64. The following table summarizes the cost of triggering the caching of all timezones, including the number of instances of some related types and the amount of extra heap required.

 

	LocalDateTime	LocalDate	ZoneInfo	ZoneOffset	Heap delta
Baseline (no TZ calls)	180	0	0
Single timezone	180	0	0	0	298
DateFormatSymbols.getZoneStrings()	57076	32212	602	1455	3760106
TimeZone.getAvailableIds() + TimeZone.getName()	36678	21674	632	1155	3024946
TimeZone.getAvalableIDs()	180	0	632	0	452578

By avoiding constructions of such tables, and relying only on FastDateParser's support for RFC-822 and GMT-style timezone names, we can avoid allocating the extra heap.