RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

[Claes Redestad]

Hi Paul,

On 2015-11-09 09:42, Paul Sandoz wrote:
> Hi Claes,
>
> How much difference are you observing?

On jake startup this removes about 22Kb, 8 classes and some 1000+ 
objects from Hello World, and much of that will never be loaded with 
this approach (Short.valueOf, Character.valueOf and Byte.valueOf are 
very rarely used). I can't really put a price tag on what this is worth 
for different users, but this is about 6% of the heap footprint of a 
minimal jigsaw image, thus I believe it'll be noticeable for embedded 
users.

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

I have a few other startup/footprint improvements I'm working on that 
targets both jigsaw specifics and java.lang.invoke infrastructure, but 
they are entirely independent of this one and other lazy initialization 
techniques I'm aware of doesn't seem worthwhile.

>
> 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];
> }

I considered this and would like to avoid it since it has potential to 
regress the hot path. It's quite possible it'll have no measurable 
effect on any benchmarks we have, but I'm still more comfortable with 
having somewhat sketchy code warts in initialization code that will only 
run once.

/Claes

> 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