]
James Perkins commented on LOGTOOL-132:
---------------------------------------
I'll see what making the class final does (I'll have to read what Andrew wrote
about it again too).
On my preliminary test, not having a final test but loading properties for translations,
the metaspace size for the classes decreases about 11%, but the total metaspace size
increased by about 1%. I'll test making it final and see what the difference is.
I've not tested performance at all yet, but I'll definitely test that too. I do
have no doubt there will be a performance impact, but hopefully we can keep it at a
minimum.
One option *might* be we have a flag which will generate the original implementation for
performance or lookups if metaspace is the concern.
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