review request (M): partial 6711911: remove HeapWord dependency from MemRegion

[John Rose]

On Jul 10, 2008, at 12:59 PM, John Coomes wrote:

> Some comments inline.
>
> John Rose (John.Rose at Sun.COM) wrote:
>> Problem:  The MemRegion type is integral to all sorts of address
>> range calculations, but it is unable to resolve offsets or size less
>> than the native word size.  This is particularly a problem with
>> compressed oops, since they are 32 bits on a 64-bit machine.  It also
>> makes MemRegions less useful (and potentially buggy) for fine-grained
>> address range calculations.
>
> As I understand it, this is a feature--it guarantees HeapWord
> alignment.  We in gc-land are the main consumers of MemRegion and so
> are mainly concerned w/objects and heap regions (e.g., old gen or
> eden), which are constrained to start and end on HeapWord boundaries.

I guess the MemRegion type needs an assert_word_aligned function, now  
that the linkage between HeapWord and oop has been broken by  
compressed oops.  The assertion could be put on all the word-wise  
constructors and accessors.

(Region alignments may also be constrained to card or page  
boundaries.  Would it be helpful to assert more general alignments  
also?)

MemRegions are also used to filter oop_oop_iterate calls, and those  
calls now visit values on 32-bit boundaries, even on 64-bit  
machines.  Since MemRegions are used to filter oop iterators, there's  
a risky mismatch, papered over by casts, when HeapWord meets oop.

For the mixed array work (and for a cleanup) I also want to get rid  
of the separate oop_oop_iterate_range loops, by refactoring them into  
oop_oop_iterate_m.  This again requires 32-bit-aligned MemRegions.

> Amen to banishing int (signed types in general) for sizes.
>
> As for scaling, the benefit mentioned above is that HeapWord alignment
> is guaranteed.  You can't have an unaligned start address or size.
> FWIW, I've always wondered about the cost of the instructions to scale
> the values.  But it's a nice form of error prevention.


Unlike most of our other error prevention measures, the cost of  
enforcing this invariant does not disappear in product mode.  (SPARC  
has to always scale the value explicitly; Intel might be able to  
escape the cost with a complex LEA instruction.)  If we use asserts  
for this invariant, the cost will disappear in product mode.

Now that there is a real bug hazard due to the oop/HeapWord mismatch,  
I think it's more urgent to get rid of scaling, as well as generalize  
MemRegion.

-- John