review request (M): partial 6711911: remove HeapWord dependency from MemRegion
John.Rose at Sun.COM
Thu Jul 10 13:59:24 PDT 2008
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
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
More information about the hotspot-dev