8252827: Caching Integer.toString just like Integer.valueOf
david.holmes at oracle.com
Sat Apr 17 05:07:35 UTC 2021
On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
> I guess the reporter meant to limit the cache range similarly to the one
> used for valueOf().
> I have no clue about the benefit/cost ratio for the proposed String
> cache. It really depends on usage, workload, etc. One can easily imagine
> both extreme scenarios but it's hard to tell how the average one would
> My post is only about either solving the issue by implementing the
> cache, which I can contribute to; or closing it because of lack of
> real-world need or interest.
Caching for the sake of caching is not an objective in itself. Unless
the caching can be shown to solve a real problem, and the strategy for
managing the cache is well-defined, then I would just close the
enhancement request. (Historically whether an issue we don't have any
firm plans to address is just left open "forever" or closed, depends
very much on who does the bug triaging in that area. :) )
> On 2021-04-16 20:36, Roger Riggs wrote:
>> Is there any way to quantify the savings?
>> And what technique can be applied to limit the size of the cache.
>> The size of the small integer cache is somewhat arbitrary.
>> Regards, Roger
>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
>>> does the enhancement proposed in  make sense, both today and when
>>> wrappers will be migrated to primitive classes?
>>> If so, it should be rather simple to add it and I could prepare a PR.
>>> If not, the issue might perhaps be closed.
>>>  https://bugs.openjdk.java.net/browse/JDK-8252827
More information about the core-libs-dev