]
James Perkins commented on LOGTOOL-132:
---------------------------------------
For loggers there is potential for it to happen many times. A mapping of log messages
can't be static on a logger as there is a {{Logger.getMessageLogger(Class<T>,
String, Locale)}} option so if the user doesn't use a static logger each instantiation
will read a properties file.
I guess the real question is going to be is the metaspace size of having a mapping of
messages vs having each string having a method going to significantly decrease the size.
My gut is for English only maybe not that much. For other languages it may be a lot more
significant.
Anyway, I'll give it a test. Removing the static strings and adding a method in
jboss-logging to remove the stack trace entry for exceptions only saves about 6% on
English interfaces.
Support low-metaspace bundles/classes
-------------------------------------
Key: LOGTOOL-132
URL:
https://issues.jboss.org/browse/LOGTOOL-132
Project: Log Tool
Issue Type: Enhancement
Reporter: David Lloyd
Priority: Critical
Metaspace is at a premium in the application server environment, and the number one
consumer is presently generated log classes.
Introduce a leaner variation on generated classes with the following requirements:
* The generated class must be {{final}}
* The generated class must contain no message strings
* The generated class must accept both a {{Logger}} and a {{Locale}}, and load its
resources from a file based on that information
* The usage of Java 8's locale lookup functionality should be considered, to support
language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
Here are some implementation ideas:
* Option 1: The resource files contain only messages, one per line, loaded directly into
a {{String[]}} instance field in the implementation class; each logging method uses a
hard-coded array index to access its message
** A key advantage is that the implementation class is very small, and consumes very
little metaspace; also, it is fast, requiring only an array lookup to acquire the string
** A disadvantage is, any change to the message set invalidates all the locale files,
which must then be regenerated
** Also, each locale file must contain all messages, unless a fallback mechanism is used
(e.g. an empty line signifies that the string should come from the parent locale)
* Option 2: The resource files contain key-value pairs, with the key being equal to the
method name
** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit
more easily from parent locales
** Disadvantage: the added overhead of mapping lines to methods (for example, using a
switch statement to map method names to fixed indexes, or loading the messages into a hash
table e.g. {{HashMap}}) will fill metaspace or impact performance, or both