On 11/08/2015 06:46 PM, Claes Redestad wrote:
It's worth considering, but j.l.reflect is already initialized by this
point in jake and I saw no real difference in heap dumps or class
loading order between this and an experiment where the ZERO constants
were simply made public. Adding methods to JavaLangAccess has its own
overheads to consider as well.
There's probably really a very minimal impact to using reflection. You
say that some code already performs reflection on Byte, Short,
Character, Integer, Long, Float, Double at boot time? The footprint
overhead is a SoftReference<ReflectionData> + an array of Field[] with
Field object(s) in j.l.Class instances for those classes. j.l.Integer
for example, contains 11 fields (static included).
Regards, Peter
/Claes
Peter Levart <peter.lev...@gmail.com> skrev: (8 november 2015 18:28:03
CET)
On 11/08/2015 06:08 PM, Peter Levart wrote:
On 11/08/2015 02:43 PM, Claes Redestad 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.
Do they have to be the same interned instances as returned from
XXX.valueOf() methods? If not, then constructing new instances
could be cheaper than using reflection which also triggers a
bunch cache initialization (think cached Field object(s) on
j.l.Class objects for wrapper classes).
I guess they have to be identical instances as returned by
XXX.valueOf() methods. An alternative to using reflection would be
making constants package-private and using SharedSecrets.
JavaLangAccess is probably already set when
sun.invoke.util.Wrapper is needed by jake or not?
Regards, Peter
Testing: verified startup/footprint improvement, various jtreg
tests
/Claes
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
