Crash using sun.misc.Unsafe.static

[John Rose]

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120717/a3dc590d/attachment.html