Superword - Aligning arrays

John Rose 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?

-- John



More information about the hotspot-dev mailing list