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