Tristan Tarrant created LOG4J2-3672:
---------------------------------------
Summary: Avoid invoking DateFormatSymbols.getZoneStrings() in
FastDateParser
Key: LOG4J2-3672
URL: https://issues.apache.org/jira/browse/LOG4J2-3672
Project: Log4j 2
Issue Type: Bug
Reporter: Tristan Tarrant
{{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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
