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.redes...@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
