[
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: 10.11.0.0
> 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
