Re: [Jikesrvm-core] regression failures 64-bit PPC

[Steve B. <Ste...@an...>]

>Because some header fields become 64 bits long in the 64 bit world ... and
>because they sometimes need to be updated atomically ... and
>because the atomic operations require 64 bit alignment ...
>
>for PPC 64 bit, BYTES_IN_PARTICLE needs to be 8. Now, it is conceivable
>that a header design might start at an offset other than 0 within the 8
>bytes. I would say that the offset within the particle is a separate issue,
>and a fully capable model would specify both alignment and offset: in
>effect a mask and value on some number of low order bits. (One could view
>this as a smaller particle size and a different kind of alignment
>constraint, I suppose.)
>
Right.  MMTk supports all of this and this is in fact what we're doing.  
BYTES_IN_PARTICLE is 4 and objects are 8 byte aligned internally.  
MMTk's allocation routines take a size, an alignment, and an offset 
which allow this very general sort of aligned allocation.

>BYTES_IN_INT is always 4, because that's given by the language semantics;
>it serves only to document why one is using the number 4.
>
But this is a problem, and one I have been trying to address.  The above 
is true of Java, but not of other languages.  MMTk tries to be neutral 
wrt to the supported language (obviously we're stuck with java as the 
implementation language).  It was for exactly this reason that I 
expunged BYTES_IN_INT from Memory.java.... ....and in doing so violated 
some unwritten assumptions and triggered this lengthy thread.

On a related note, I suggest we rename PARTICLE to be 
MINIMUM_ALIGNMENT.  As far as I can tell, this is what it is.  I think 
this name makes more sense as it is informative and it has symmetry with 
our existing MAXIMUM_ALIGNMENT.  Unless there are objections I will go 
ahead and make this change soon.

--Steve