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