Superword - Aligning arrays

[James Walsh]

Thanks again for the help.  I probably wouldn't be to where I am now for another couple months without it.  While looking through the GC code it appeared to me that the heap is traversed by grabbing a pointer and then indexing through based on the size of the oop headers.  If that is the case then how would I deal with arrays that don't end up on the object alignment boundary?  I assume that if I alter the length of the array it will show up in the java code if someone is indexing through an array until array.length.  Do I need to change how the size of the oop is computed to take into account the possibility of a extra alignment word?



----- 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: Wednesday, February 4, 2009 5:47:37 PM
Subject: Re: Superword - Aligning arrays

On Feb 3, 2009, at 11:19 AM, James Walsh wrote:

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

Look in space.hpp at Space::allocate and par_allocate.  Those virtuals are both defined and called in very many places.  At a minimum, each implementation would have to insert the alignment correction before affected objects.

You know, it would probably simplify matters (deep down in the GC) to strongly align *all* objects bigger than a certain threshold, not just arrays.  Then your alignment logic would simply compare the requested size against the threshold, rather than ask potentially expensive questions about exactly which kind of object were being allocated.  Or (thinking out loud) the alignment request could be passed in as an additional boolean argument to [par_]allocate.

> 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()?

Yes.  Look for this comment in generate_block_arraycopy:
  // One more chance:  Pick off an initial 32-bit word.

There's similar logic in ClearArrayNode::clear_memory, too.

You're making progress, I think, but it's not an easy problem.  Good luck!

-- John