On 01/25/2013 05:42 PM, Aleksey Shipilev wrote:
On 01/25/2013 08:37 PM, Peter Levart wrote:
On 01/25/2013 05:34 PM, Aleksey Shipilev wrote:
80 4 ClassValueMap Class.classValueMap
84 12 (alignment/padding gap)
What's this? why 12 bytes?
96 4 int Class.classRedefinedCount
Beats me, some voodoo VM magic? This is what Unsafe reports anyway. Your
data have the same gap (though not immediately evident because you don't
calculate the offset differences).
-Aleksey.
j.l.Class seems to be very special with it's own layout lo(ma)gic. For
example, I copied the source of j.l.Class into j.l.MyClass and
chopped-out all the methods, which gives the following (32 bit pointers):
java.lang.MyClass instance field offsets:
Field Type Field Name Offset
---------- ---------- ------
* int classRedefinedCount 12**
** int lastAnnotationsRedefinedCount 16*
Constructor cachedConstructor 20
Class newInstanceCallerCache 24
String name 28
SoftReference reflectionData 32
ClassRepository genericInfo 36
Object[] enumConstants 40
Map enumConstantDirectory 44
Map annotations 48
Map declaredAnnotations 52
AnnotationType annotationType 56
ClassValueMap classValueMap 60
the primitive fields come before pointers whereas in j.l.Class:
java.lang.Class instance field offsets:
Field Type Field Name Offset
---------- ---------- ------
Constructor cachedConstructor 12
Class newInstanceCallerCache 16
String name 20
SoftReference reflectionData 24
ClassRepository genericInfo 28
Object[] enumConstants 32
Map enumConstantDirectory 36
Map annotations 40
Map declaredAnnotations 44
AnnotationType annotationType 48
ClassValueMap classValueMap 52
* int classRedefinedCount 80**
** int lastAnnotationsRedefinedCount 84*
...they come after the pointers and the first one has a strange alignment...
Regards, Peter