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

[Peter B. Kessler]

We already have

     4718395 RFE Size confusion in GC interface and implementation
     4718400 Bug Many quantities are held as signed that should be unsigned.

that could be used to address some of these issues.

			... peter

John Rose wrote:
> 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