RFR: 8047818: G1 HeapRegions can no longer be ContiguousSpaces

Mikael Gerdin mikael.gerdin at oracle.com
Wed Jun 25 06:56:56 UTC 2014


Jon,

On Tuesday 24 June 2014 09.34.57 Jon Masamitsu wrote:
> On 06/24/2014 07:43 AM, Mikael Gerdin wrote:
> > Jon,
> > 
> > On Tuesday 24 June 2014 07.26.52 Jon Masamitsu wrote:
> >> Mikael,
> >> 
> >> Did you consider creating a base class for ContiguousSpace and
> >> G1OffsetTableContigSpace that has a  _top but does not assume
> >> parsability?
> > 
> > I did consider it but I thought that the added complexity of having even
> > more levels of inheritance were not worth the benefit of sharing the _top
> > field. Especially since G1 attempts to hack around the semantics around
> > the _top field with respect to concurrent access. See the disjunction I
> > removed from allocate_impl and when G1 calls cas_allocate and allocate.
> 
> Ok.  That's enough of a reason.

Thanks. I'm planning on filing an RFE for unifying the allocation code between 
G1 and ContiguousSpace somehow.

> 
> >> Could allocate_inner() have been called allocate_impl() as it is
> >> in ContiguousSpace?  I don't know what the "inner" in the name
> >> is telling me.
> > 
> > "inner" tries to signal that this function is internal and wrapped by
> > other
> > methods providing the external API. I don't have a particular naming
> > preference here, if the other reviewers are fine with "impl" or don't have
> > a preference I'm fine with changing it.
> 
> If no one objects, the "impl" has more of a meaning to me.

Ok, naming it "impl" also makes it closer to the ContiguousSpace version.

> 
> 
> http://cr.openjdk.java.net/~mgerdin/8047818/webrev/src/share/vm/gc_implement
> ation/g1/heapRegion.inline.hpp.frames.html
> 
> You use the  if-then {return ...} return NULL style.
> 
>    52 inline HeapWord* G1OffsetTableContigSpace::allocate_inner(size_t size)
> { 53   HeapWord* obj = top();
>    54   if (pointer_delta(end(), obj) >= size) {
>    55     HeapWord* new_top = obj + size;
>    56     assert(is_aligned(obj) && is_aligned(new_top), "checking
> alignment"); 57     set_top(new_top);
>    58     return obj;
>    59   }
>    60   return NULL;
>    61 }
> 
> The ContiguousSpace uses the if-then {return ...} else {return NULL} style.
> 
> Any reason not to use the same style?

No good reason. I'll keep the new ones in the same style.

> 
> block_is_obj() seems more like an is_in() method.
> 
>    89 inline bool
>    90 HeapRegion::block_is_obj(const HeapWord* p) const {
>    91   return p < top();
>    92 }
> 

It's actually the same as ContiguousSpace::block_is_obj
When G1 class unloading is integrated the implementation of 
HeapRegion::block_is_obj will change.

> 
> Could you add a specification for this block_size()?
> 
>    94 inline size_t
>    95 HeapRegion::block_size(const HeapWord *addr) const {
>    96   const HeapWord* current_top = top();
>    97   if (addr < current_top) {
>    98     return oop(addr)->size();
>    99   } else {
>   100     assert(addr == current_top, "just checking");
>   101     return pointer_delta(end(), addr);
>   102   }
>   103 }

Similar to block_is_obj this is currently the same as the ContiguousSpace 
variant. When G1 class unloading is integrated the implementation will change.

The other declarations of block_size are not that clearly specified, can you 
elaborate on what kind of specification you are looking for?

/Mikael

> 
> Jon
> 
> >> I've just started on the review so more to come.
> > 
> > Great!
> > 
> > Thanks
> > /Mikael
> > 
> >> Jon
> >> 
> >> On 06/23/2014 07:26 AM, Mikael Gerdin wrote:
> >>> Hi!
> >>> 
> >>> When G1 is modified to unload classes without doing full collections the
> >>> old HeapRegions can contain unparseable objects. This makes
> >>> ContiguousSpace unsuitable as a base class for HeapRegion since it
> >>> assumes that all objects below _top are parseable.
> >>> 
> >>> Modify G1OffsetTableContigSpace to implement allocation with a separate
> >>> _top and reimplement some Space pure virtuals to make object iteration
> >>> work as expected.
> >>> 
> >>> This change is the last part of a set of 4 changes: 8047818, 8047819,
> >>> 8047820, 8047821 which are needed to refactor the HeapRegion class and
> >>> its superclasses in order to simplify the G1 class unloading change
> >>> which
> >>> is coming. This change depends on the 19, 20 and 21 changes.
> >>> 
> >>> Bug:
> >>> https://bugs.openjdk.java.net/browse/JDK-8047818
> >>> Webrev:
> >>> http://cr.openjdk.java.net/~mgerdin/8047818/webrev/
> >>> 
> >>> Notes:
> >>> The moving of set_offset_range is due to an introduced circular
> >>> dependency
> >>> between g1BlockOffsetTable.inline.hpp and heapRegion.inline.hpp
> >>> 
> >>> Thanks
> >>> /Mikael




More information about the hotspot-gc-dev mailing list