Initial preview: JEP-149 Reduced Class instance size

[Martijn Verburg]

Hi Hinkmond,

Is there a corpus of code you can look at in the embedded space to see what
ratio of real-world apps use a lot of reflection?  We have access to a
corpus in the SE space (some Cambridge PhD students that work with us) and
I know Brian/Joe et al use one internally at Oracle as well, would be an
interesting comparison.

Cheers,
Martijn


On 5 April 2012 09:07, Hinkmond Wong <hinkmond.wong at oracle.com> wrote:

> 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/<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<http://www.oracle.com/commitment>>
> Oracle is committed to developing practices and products that help protect
> the environment
>
>