Hi,
in view of Integer becoming a primitive class [1], the IntegerCache is
probably going to disappear.
For a small, fixed range like the one you are proposing [-1, 16],
there's no real need for a separate cache class. You could have a switch
in the implementation of toString(), with the string literals then being
part of the constant pool of the class. Not free beer, but supported by
the VM since day 0.
It's only when the range is open that you'd need a cache similar to
IntegerCache.
My 2 cents as well :-)
Raffaello
----
[1] https://openjdk.java.net/jeps/402
On 2021-04-17 11:18, Laurent Bourgès wrote:
Hi,
I read the JBS bug and I interpret it as:
- IntegerCache provides Integer instances for [-128, 127] by default
- Having Integer.toString(int) could behave the same or at least cache
most probable values like [-1 to 16] or using the IntegerCache range.
It looks trivial and potentially could benefits to jdk itself to reduce
memory garbage : is Integer.toString(int) widely used in the jdk codebase ?
Finally it can be alternatively implemented in application's code.
My 2 cents,
Laurent
Le sam. 17 avr. 2021 à 11:06, Raffaello Giulietti
<raffaello.giulie...@gmail.com <mailto:raffaello.giulie...@gmail.com>> a
écrit :
On 2021-04-17 07:07, David Holmes wrote:
> 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 look.
>>
>> 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. :) )
>
> Cheers,
> David
>
Indeed, the impression is that many of the issues are probably open
because it's unclear whether they should be addressed with some
implementation or spec effort or whether they should be closed.
Triaging
is certainly a harder job than it appears at first sight ;-)
It would be useful to have a kind of "suspended" or "limbo" resolution
state on the JBS for issues like this one, so people searching for more
compelling open ones would not encounter them.
Personally, I would close this issue without a "fix"; or "suspend" it.
Greetings
Raffaello
>>
>> Greetings
>> Raffaello
>>
>>
>> On 2021-04-16 20:36, Roger Riggs wrote:
>>> Hi,
>>>
>>> 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:
>>>> Hello,
>>>>
>>>> does the enhancement proposed in [1] 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.
>>>>
>>>>
>>>> Greetings
>>>> Raffaello
>>>>
>>>> ----
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
<https://bugs.openjdk.java.net/browse/JDK-8252827>
>>>
