]
David Lloyd commented on LOGTOOL-132:
-------------------------------------
I don't think we'll see a huge drop in performance in the single-logger case:
you're still reading the same number of bytes out of the zip file. The biggest
question in my mind is, how do we cache the set of strings so they can be shared across
instances? Having a single-entry cache that has a locale+string array would probably be
good enough. We don't change locales often (well, ever, really) but if we do, I'd
expect that it's OK to take a perf hit in that case.
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