Urgh. In that case the array base offset should be specified in the constructor of an MMType - JikesRVM doesn't have this problem, because the object pointer always points to element 0 of an array irrespective of header sizes and alignment issues (and hence the align and offset parameters to 'alloc'). I was brought up to believe that a fixed offset to the first data field was a performance win - has it been measured ?
I'll have a look at doing this in MMTk, but probably not until after OOPSLA. cheers > Weldon Washburn wrote: >>> I actually stumbled on this bug during bringup. I replaced >>> ...plus(arrayOffset)... with ...plus(12)... Its a hack. But now it >>> looks >>> like I simply set ARRAY_BASE_OFFSET to 12 during <clinit>. Does this >>> seem >>> right?? > > By the way, the array base offset may differ depending on the platform and > array type. > As as I know, currently on 32 bit platform (ia32) the array base offset > is 12 for types of size <= 4. > Double[] and long[] arrays have array base offset 16. > > on 64 bit platforms, if the vtable pointers are compressed (they are now), > the array base offset is the same as on 32 bit platforms. > > Should someone disable vtable reference compression, the array base offset > will be always 16 (8 bytes vptr + 4 bytes flags + 4 bytes array size). > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
