Hi Brian,
One of the issues we have in the Java Embedded group (as David points
out in his summary), is that while on paper the theoretical max savings
seems great (as you point out also), in practice as David points out in
his note, this might be a wash if there are a lot more reflection using
classes vs. non-reflection using classes in "typical" real-world
applications, not the low or zero reflection using class ratio that
happens in the theoretical "best case".
So, a question comes up if we should judge the merit of this change on
the theoretical "best case" scenario, or should we judge it on
real-world applicability to "typical" apps (such as a finite set of
customer surveyed embedded apps that we feel represent a real-world
scenario).
Thanks,
Hinkmond
On 4/4/12 8:28 PM, Brian Goetz wrote:
Reducing the number of SoftReferences in ReflectionHelper also seems
an attractive target for memory reduction. Rather than eight soft
references (eight extra objects), maintaining a SoftRef to the entire
RH, or at least to the part of the RH that is currently SR'ed if the
two non-SR'ed fields can't be recomputed, would save you a whole pile
of objects per class (and might also reduce pressure on GC, having 8x
fewer SRs to process.)
Finally, you may be able save an extra field per Class by storing the
ReflectionHelper in a ClassValue on Java SE 8, rather than a field.
On 4/4/2012 10:50 PM, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/
This is an early look at a proposed change to reduce the instance size
of Java Class objects in the common case that reflection is not used.
In SE 7 a java.lang.Class instance is 104 bytes on 32-bit systems. It
consists of the 8-byte object header, 19 declared fields and 5 injected
fields (fields added by the VM as-if they were declared in
java.lang.Class but which do not appear in the Java source code). There
are 10 reference fields associated with reflection caching that can be
moved to a helper object with no impact on the VM or serialization
protocols. Adding back a reference for the helper, that saves 9
references. Notionally this is 36 bytes on 32-bit but due to 8-byte
alignment it only saves 32 bytes. That gives a size of 72 bytes - a
reduction of 30%. This initial modification has been prototyped for
initial performance measurements.
Note that if reflection is used then the amount of memory used by the
Class will increase by 8-bytes - that being the additional object header
of the ReflectionHelper instance. So the net gain depends on the ratio
of reflection using classes to non-reflection-using classes in an
application.
Please note that I've put this out just before I disappear on vacation
for 10 days, so if you don't see any responses from me that is why. :)
Thanks,
David Holmes
--
Oracle <http://www.oracle.com>
Hinkmond Wong | Consulting Member of Technical Staff
Phone: _+1 408.276.7618_ | Fax: _+1 408.276.7674_
Oracle Java Embedded
4210 Network Ci., M/S USCA22-rm2364 | Santa Clara, CA 95054
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
