]
James Perkins commented on LOGTOOL-132:
---------------------------------------
I'll do some experimenting today. I kind of wonder how much metaspace we'll really
save by removing the {{*$str()}} methods. By removing those methods there's definitely
going to be more I/O happening.
By removing the static strings and just returning the string from the {{*$str()}} method
as well as creating a static method in jboss-logging to trim the stack trace I was able to
save some metaspace.
*Before Change*
||Index||Super||Total||ClassName||
|604|5115|136592|org.jboss.as.server.logging.ServerLogger_$logger|
|602|5104|127624|org.jboss.as.server.logging.ServerLogger_$logger
*After Change*
||Index||Super||Total||ClassName||
|1561|5115|97312|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
|1562|5104|91152|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
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