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

Reply via email to