On 6/30/2014 9:51 PM, Christian Thalinger wrote:
On Jun 30, 2014, at 5:50 PM, Coleen Phillimore <coleen.phillim...@oracle.com>
wrote:
On 6/30/14, 3:50 PM, Christian Thalinger wrote:
private Class(ClassLoader loader) {
// Initialize final field for classLoader. The initialization value
of non-null
// prevents future JIT optimizations from assuming this final field
is null.
classLoader = loader;
+ componentType = null;
}
Are we worried about the same optimization?
Hi, I've decided to make them consistent and add another parameter to the
Class constructor.
http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/
The jdk change looks okay while I am beginning to think whether we really want
to keep expanding this constructor to deal with this future JIT optimization
(you will be moving more fields out from the VM to java.lang.Class).
There are places in JDK initializing the final fields to null while the final
field value is overridden via native/VM - e.g. System.in, System.out, etc. I
would prefer reverting the classLoader constructor change to expanding the
constructor for any new field being added. Handle it (and other places in JDK)
when such JIT optimization comes.
Mandy
