db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6230) Use the JVM's cache of Number instances in ReuseFactory
Date Tue, 28 May 2013 11:45:22 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-6230:

    Attachment: derby-6230-01-a.diff

All tests ran cleanly with derby-6230-01-a.diff, which changes ReuseFactory so that it calls
{Byte,Short,Integer,Long}.valueOf() instead of maintaining its own cache.

With one exception, all values that were previously available from the cache are still returned
without allocating a new instance. The exception is Integer.MAX_VALUE, which was one of the
special cases in the original code. That value is not guaranteed to be cached by Integer.valueOf(int).

I chose to not add a special case for Integer.MAX_VALUE in the patch, as I'm fine with leaving
it to the JVM to decide which values are worthwhile caching, and the net effect of the change
is that more values are taken from the cache even though it's not a superset of the old values.
However, if someone thinks ReuseFactory.getInteger() should still have a special case for
Integer.MAX_VALUE, I'm fine with reintroducing it too.
> Use the JVM's cache of Number instances in ReuseFactory
> -------------------------------------------------------
>                 Key: DERBY-6230
>                 URL: https://issues.apache.org/jira/browse/DERBY-6230
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: derby-6230-01-a.diff
> ReuseFactory has a cache of Byte, Short, Integer and Long instances to avoid excessive
allocation of such instances.
> As of Java 5, the JVM has a cache of its own, available through static valueOf() methods
in these classes.
> The JVM's cache is guaranteed to have at least all values in the range [-128, 127]. ReuseFactory
currently caches Integer instances in the range [-1, 18] plus a few special values, and Byte,
Short and Long instances in the range [0, 10].
> If we change ReuseFactory so that it uses the JVM's cache, the number of cache misses
will be lower, and the code will become shorter.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message