Currently HotSpot VM allocate java  customer  fileds according to thir type
in the next order:

oops        (32-bits for LP32, 64-bits for LP64)
long/double (64-bits fileds)
int/float   (32-bits fileds)
short/char  (16-bits fileds)
byte        ( 8-bits fileds)  

The other stype could be source based.

Also we could compact fields by placeing them into gaps between fields in super class.
Posted Date : 2007-02-09 23:16:27.0

N/A

Different styles of java object nonstatic fields allocation provide
performance improvement.
Posted Date : 2007-02-27 18:26:55.0

internally, filling the gaps between fields that are creating themfor alignment reasons could effectively reduce the memory footprint for objects at runtime.It shoud not affect the compatibility, provided that direct accesses to the object structure (in JNI) is not affected. However some of these assumptions may be wrong because some parts of the defaultserializationof objects depend on their order in memory.

Anyway, it's always a good idea to structure the variable members in a classsothat they get properlyaligned, bygrouping them by decreasing size (however member reference variables should better beat the begining of instances, as it benefits of faster runtime code for dereferencing them.

Nowsuppose that there remains gaps in an instance of class A, will thesegaps be usable for fields defined in class B derived from A? Normally it should be possible to do that without affecting the way class A works; except that the code that initializes instances of class A may assume that thesegaps are unused, so it couldoverwrite them when zeroing it completely...

A related optimization would be for arrays of instances: if we have the longest type taking 8 bytes, and forcing object alignment to multiple of 8, there will remain gaps up to 7 bytes. But given any index position in the array, these gaps could still be filled by using (index&7) as a condition for computing the position of a field relative to the computed "start" address of an instance within that array.

Example:
class A{ public long L;byte B;}
Look at the gaps in arrays of type A[]: this is the worst case, with 7 bytes wasted per instance.
However we can respect the alignment constraint for the field l using this placement strategy:
addr=0: x[0].L : field_offset=0 ; address of x[0]
addr=8: x[0].B : field_offset=0
addr=9: x[1].B: field_offset=-7
addr=10: x[2].B: field_offset=-14
addr=11: x[3].B : field_offset=-21
addr=12: x[4].B : field_offset=-28
addr=13: x[5].B : field_offset=-35
addr=14: x[6].B : field_offset=-42
addr=15: x[7].B: field_offset=-49
addr=16: x[1].L: field_offset=0 ; address of x[1]
addr=24: x[2].L: field_offset=0 ; address of x[2]
addr=32: x[3].L: field_offset=0 ; address of x[3]
addr=40: x[4].L: field_offset=0 ; address of x[4]
addr=48: x[5].L: field_offset=0 ; address of x[5]
addr=54: x[6].L: field_offset=0 ; address of x[6]
addr=60: x[7].L: field_offset=0 ; address of x[7]
addr=68: the allocation pattern is repeated here.

With this scheme, the address of instances in the array is not constant, but isstill easy to compute by taking the index of the element modulo 8; each group of 8 elements has a constant size. The offset of fields within each case depends only on (index&8)...
And anarray of such object will just use the average size. This will work for compacting arrays (for single objects, final gaps can't be used, but the allocation strategy for fields is exactly like the field offsets computed for index 0 in an array of 1 element.