Superword - Aligning arrays
John.Rose at Sun.COM
Wed Feb 4 15:42:33 PST 2009
On Feb 4, 2009, at 9:40 AM, James Walsh wrote:
> 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?
In general, the heap must always be "parseable" into objects in this
way. (There are exceptions; the tail-end of a TLAB and certain other
unused areas can contain complete garbage. Also, concurrent marking
requires extra semi-parseable intermediate states. As the GC guys for
more info; that's about all I know.)
So, in this case, if a big object must be aligned strongly, you have
to insert a little half-sized filler object before it, to "bump it
up". The filler object must be a valid object (or at least parseable
as a heap block). So when the heap is scanned, the scan comes first
to the filler, reads the header, and skips up to the next object,
which is the big, aligned array. Make sense?
> 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
There's no need to change array.length here.
(I suppose you could consider changing oopDesc::size_given_klass for
big objects to add extra round-ups to the size. Beware: That routine
(along with its variations) is performance-critical. See also uses of
align_object_size and MinObjAlignmentInBytes. Wherever those guys
appear, if a large object is a possibility, you would have to put a
conditional to apply the correct alignment.)
But that's probably more trouble than it's worth. If you insert the
filler objects to bump up the alignment, you can let the tail of the
big array be as unaligned as any other object, as long as you never
perform vector writes that cross the ragged end of the array. That's
simpler. Inserting padding objects is much less risky than changing
the object sizing or heap-parsing logic.
More information about the hotspot-dev