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> 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 > >>> >
