8252827: Caching Integer.toString just like Integer.valueOf

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Apr 30 20:36:46 UTC 2021


Ciao Raffaello,
another general consideration: caching sometimes makes certain 
optimizations harder to pull off.

Few years ago I've seen this talk at Fosdem:

https://archive.fosdem.org/2020/schedule/event/reducing_gc_times/

See minute 5:53 - where it shows that cached Integer values (as per 
Integer::valueOf) inhibit scalarization, and using `new Integer(...)` 
leads to superior performances.

It's a pattern I have observed several time when working with the 
Foreign Memory API, where most of the abstractions are immutable: 
attempting to cache things (e.g. MemoryAddress instances) often comes up 
with the same GC overhead (because these instances are escape analyzed 
away) and ends up with worse performance overall (loss of scalarization).

Of course this is not _always_ the case - but I wanted to add this 
particular angle to the discussion.

Cheers
Maurizio

On 16/04/2021 17:48, 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


More information about the core-libs-dev mailing list