review request (M): partial 6711911: remove HeapWord dependency from MemRegion
John.Rose at Sun.COM
Wed Jul 9 18:38:42 PDT 2008
(Sent to the general list, since MemRegion is a low-level class used
in many places.)
I've been working on object layout extensions, and have run into a
limitation in the MemRegion type that I want to fix. Since a proper
fix will require a number of trivial code touches, I thought I'd send
out a heads-up.
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.
Solution: Make the dependency on word size more explicit by putting
the word "word" into MemRegion member functions that depend somehow
on the HeapWord type. Add byte-wise versions of the member
functions, putting the word "byte" into them. The existing member
functions are given a neutral "void*" type (or they could be removed).
The slight downside of this is that about half of the uses of the
"start" and "end" member functions appear to be linked to an
assumption about HeapWord, while the others look like pure (unscaled)
addresses. When I recompile the system with the "start" and "end"
changed to return "void*", the places where those pointers are mixed
with HeapWord, or subject to address arithmetic, pop up as errors and
I change them to "start_word" and "end_word". These are the trivial
code touches. The benefit of this process is that each code touch
can be evaluated for whether it masks a bug with compressed oops.
P.S. I think this change moves in the right direction along another
path, which is replacing many size computations in the JVM with
size_t instead of int scaled by HeapWord. I suspect (though am not
sure) that there is no benefit to using scaled sizes (an int scaled
by HeapWordSize). So eventually I think we should measure object
sizes and offsets with an unscaled size_t. In any event, using int
instead of size_t (scaled or not) creates a constant overflow hazard
on 64-bit systems.
More information about the hotspot-dev