On 2015-11-08 20:40, Peter Levart wrote:
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
You're mostly right: the ReflectionData is all hiding behind that
soft-referenced ReflectionData, so in the HeapDumpAfterFullGC dumps I've
been looking at those instances must've been cleared. However, the heap
itself had grown an extra 25Kb in the reflection case, so I'll go with
SharedSecrets approach for now.
On 2015-11-08 21:35, Aleksey Shipilev wrote:
a) Pulling ZERO via Reflection: is this actually the best we can do? I
have no answer, but this does look moderately ugly. I agree that
exposing these constants as public is not good, as it precludes further
improvements in autoboxing elimination.
Sure, see above.
b) Given that startup code is probably running in interpreter, doing the
compiler's job in loop splitting to avoid branch for zero seems a good
tactics, so:
* Byte loop should use the same idiom as Char:
cache[0] = ZERO;
for (int i = 1; ...) {
...
}
No, ByteCache goes from -128 to 127.
* Integer/Long/Short loops may look better if we split the loop into
"negative", ZERO, and "positive" parts?
Sure, this might get a bit ugly, but here's my take:
http://cr.openjdk.java.net/~redestad/8141678/webrev.02/
Thanks for looking at this!
/Claes
