On 07/18/2012 12:55 AM, John Rose wrote: > On Jul 16, 2012, at 4:06 PM, Krystal Mok wrote: > >> And you're right that this has to do with the PermGen removal >> project. The difference comes from [1], which is a part of CR 7017732. >> To be specific, before the 7017732, static fields are stored in the >> instanceKlass of a Java class; an instanceKlass (or its enclosing >> klassOopDesc to be exact) is not an Java object. >> After 7017732, static fields are moved to the tail of java.lang.Class >> instances, which are Java objects. >> >> So to answer your question, you just shouldn't expect the the code to >> work in JDK6/HotSpot. > > The API for unsafe access to statics is designed to allow > implementations to do one of two things: > > 1. store a static variable at a fixed offset within a managed object > (addressable via Java references) > 2. store a static variable at an arbitrary but fixed 64-bit VA (in > which case the object base is just null) > > The JDK 6 system is in a middle state, where the instanceKlass is a > managed object and can move is not compatible with Java references. > I think there was a time when non-Java oops could be manipulated via > Java reference variables, but the practice has always been rather… unsafe. > > This could be fixed in JDK 6, but it's probably not worth it. I > recommend spinning bytecoded accessors for statics on JDK 6. On JDK 7 > and later, the Class is the base (as Kris pointed out). This is > probably how it's going to stay.
I spin bytecode by default if the field is visible from the callsite and wanted to use unsafe with a constant base object if the field is not visible. So to workaround that bug, I store the base object in a non-constant field exactly like reflection does, so it works on jdk6. Exactly, I should try to detect if the VM is hotspot or not because neither JRockit nor J9 have the same issue. > > Thanks for the report. > > — John > > P.S. For multi-tenancy VMs, the addressing arithmetic for statics > would need to take into account the task ID. But the above design > (baseOrNull + longOffset) still works, since the unsafe API doesn't > say how the two components get combined. Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev