Superword - Aligning arrays

[James Walsh]

I must not be looking in the right files for the array reallocation code.  Can you dumb it down and give me a file name and line number?  I'm guessing that option 1 is a no go since it will explode memory usage with dead space and only doing SIMD on longs/doubles isn't going to work for me so I guess I'm going to give option 3 a try.  Is the C2 arraycopy intrinsic you refer to LibraryCallKit::inline_arraycopy()?




----- Original Message ----
From: John Rose <John.Rose at Sun.COM>
To: James Walsh <groundskeeperwiley at yahoo.com>
Cc: hotspot-dev at openjdk.java.net
Sent: Tuesday, February 3, 2009 5:01:46 PM
Subject: Re: Superword - Aligning arrays

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