Superword - Aligning arrays
John.Rose at Sun.COM
Mon Feb 2 15:01:46 PST 2009
On Feb 2, 2009, at 9:27 AM, James Walsh wrote:
> I have the arrays aligned now and the SIMD ops run properly until I
> hit garbage collection. I have a couple questions about that.
> Where do I need to look to make sure the array payloads are aligned
> after collection?
Look at the GC code which reallocates the arrays. It will have to
insert dummy objects in order to make up the necessary alignment for
the new (relocated) copy of the big array.
> Also I think when garbage collction starts it checks to see that the
> array objects are aligned on 8byte boundaries. On the 32bit machine
> I'm working on the float array headers are 12bytes so those array
> objects are not going to be object aligned on 8bytes. Should I
> eliminate object alignment checks for arrays?
Probably not, since somebody is likely to use the low 3 bits of
pointers for tagging.
> Or is there a better way of getting around that problem?
Note that arrays of longs and doubles have an internal word (after the
length field) to make up the base alignment. In the interest of
compactness, other arrays do not have the padding word.
As I see it, your choices are:
1. add the padding word to other arrays also (risking more
fragmentation overhead even for small arrays)
2. confine your SIMD work to long and double arrays
3. arrange the loop logic for non-long/double arrays to deal with the
odd leading word
Last tine I touched the C2 arraycopy intrinsic, I took option 3 and it
wasn't that bad. If you are going to vectorize loops, you have to
deal with leading and trailing ("fore-n-aft") partial vectors, in any
case. Constraining the alignment removes a different degree of
freedom, and it makes the leading case easier, at any rate.
So I'd recommend 3, or 2, or 1, in that order.
Does that make sense?
More information about the hotspot-dev