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

[David Lloyd (JIRA)]

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

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



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