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