8252827: Caching Integer.toString just like Integer.valueOf

[Raffaello Giulietti]

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.giulietti at gmail.com <mailto:raffaello.giulietti at 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>
>      >>>
>