RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches
Paul Sandoz
paul.sandoz at oracle.com
Mon Nov 9 08:42:46 UTC 2015
Hi Claes,
How much difference are you observing?
If it is small perhaps it’s worth waiting to see if there are much larger improvements we can make, as the non-obvious tight coupling also has it’s own cost in terms of maintenance.
Can we avoid shared secrets by doing the following?
@HotSpotIntrinsicCandidate
public static Byte valueOf(byte b) {
if (b == 0) return ZERO;
final int offset = 128;
return ByteCache.cache[(int)b + offset];
}
Paul.
> On 8 Nov 2015, at 14:43, Claes Redestad <claes.redestad at oracle.com> wrote:
>
> Hi,
>
> indy eagerly creates and initializes all integral type caches (Byte$ByteCache, Short$ShortCache) which has a small, measurable
> impact to jake startup and footprint. Exposing ZERO constants from Byte, Character, etc which are guaranteed to be identical to what's
> returned from each respective valueOf(0) enables j.l.i. to initialize without eagerly creating these caches:
>
> webrev: http://cr.openjdk.java.net/~redestad/8141678/webrev.01
> bug: https://bugs.openjdk.java.net/browse/JDK-8141678
>
> Making these constants public would allow us to not fetch them via reflection for a tiny, incremental startup improvement, but I don't
> think the constants carry their own weight to motivate them becoming part of public API.
>
> Testing: verified startup/footprint improvement, various jtreg tests
>
> /Claes
More information about the core-libs-dev
mailing list