[jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes

[James Perkins (JIRA)]

    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524017#comment-13524017 ] 

James Perkins commented on LOGTOOL-132:
---------------------------------------

I think I'm just going break compatibility and remove the previous properties which allowed the generated implementation to work with 3.0.x. For compiling I'll throw an exception if the correct minimum version of {{jboss-logging}} isn't used. I think it will just make it easier. Keeping the compatibility is likely just going to complicated the generated code and we should really leave it very simple as the goal is shrinking the metaspace size.

I seem to have this working well locally. There are few main issues left:
# There was a way for a default locale, LOGTOOL-116, to be set. Given the same implementation is used for all languages we need to away to determine which locale should be used for translated messages vs fallback messages.
# We need to figure out how we fallback from {{fr_CA}} to {{fr}} if both properties files exist
# Performance testing needs to be done.

One kind of interesting thing, and something I'll look at in more depth, is while the implementations seem to be down about 50% in metaspace size the total only seems down about 1%. 

> 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



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)