On 07/02/2014 02:22 PM, Peter Levart wrote:
On 07/02/2014 08:26 AM, Mandy Chung wrote:
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
What about:
private Class() {
classLoader = none();
componentType = none();
...
}
private <T> T none() { throw new Error(); }
I think this should be resistant to future optimizations.
And you could even remove the special-casing in
AccessibleObject.setAccessible0() then.
Regards, Peter
Regards, Peter
