[
https://issues.apache.org/jira/browse/LOG4J2-3672?focusedWorklogId=884368&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-884368
]
ASF GitHub Bot logged work on LOG4J2-3672:
------------------------------------------
Author: ASF GitHub Bot
Created on: 10/Oct/23 20:24
Start Date: 10/Oct/23 20:24
Worklog Time Spent: 10m
Work Description: vy commented on PR #1848:
URL: https://github.com/apache/logging-log4j2/pull/1848#issuecomment-1756169179
@tristantarrant, thanks so much for taking time to not only report the
problem, but also provide a fix. :bow: I have some concerns regarding this
change. For one, it is backward incompatible, hence we cannot have your toggle
enabled by default. Nevertheless, I think we don't need a toggle:
`FastDateParser` can do better than matching against an enormous regex to
figure out the time zone.
Since `FastDateParser` is borrowed from Apache Commons Lang in 2015 (ouch!),
I'd first check if the upstream already has a fix for this. Otherwise, I'd try
to figure out a better way. All in all, I have an inkling that we can do better
a regex.
Issue Time Tracking
-------------------
Worklog Id: (was: 884368)
Time Spent: 20m (was: 10m)
> 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
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{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)
