RFR: 8213890: Implementation of JEP 344: Abortable Mixed Collections for G1

Stefan Johansson stefan.johansson at oracle.com
Tue Nov 27 19:36:14 UTC 2018


Thanks for the review Kim,

Two new webrevs, I'll let you decide which way to go, I kind of prefer 
version b.
Full a: http://cr.openjdk.java.net/~sjohanss/8213890/03a/
Inc a:  http://cr.openjdk.java.net/~sjohanss/8213890/02-03a/
Full b: http://cr.openjdk.java.net/~sjohanss/8213890/03b/
Inc b:  http://cr.openjdk.java.net/~sjohanss/8213890/02-03b/

Comments below.

On 2018-11-27 03:20, Kim Barrett wrote:
>> On Nov 26, 2018, at 4:03 PM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
>>
>> Thanks Thomas,
>>
>> Updated webrevs
>> Full: http://cr.openjdk.java.net/~sjohanss/8213890/02/
>> Inc: http://cr.openjdk.java.net/~sjohanss/8213890/01-02/
> 
> Looks good.
> 
> Just a few very minor things, which you can do or not.
> 
> ------------------------------------------------------------------------------
> src/hotspot/share/gc/g1/g1CollectionSet.cpp
>   105 void G1CollectionSet::initialize_optional(uint max_length) {
> 
> Consider also asserting _option_region_length == 0.
Fixed, also added assert for _optional_region_max_length == 0.

> 
> ------------------------------------------------------------------------------
> src/hotspot/share/gc/g1/g1CollectionSet.cpp
>   451 bool G1CollectionSet::optional_is_full() {
> 
> Consider asserting _optional_region_length <= _option_region_max_length.
Good point, added.

> 
> ------------------------------------------------------------------------------
> src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
>    40 G1ParScanThreadState::G1ParScanThreadState(G1CollectedHeap* g1h,
> ...
>    86   _oops_into_optional_regions = NEW_C_HEAP_ARRAY(G1OopStarChunkedList, _num_optional_regions, mtGC);
>    87   for (size_t i = 0; i < _num_optional_regions; i++) {
>    88     ::new (_oops_into_optional_regions + i) G1OopStarChunkedList();
>    89   }
> 
> Why not something like
> 
>    _oops_in_optional_regions = new G1OopStarChunkedList[_num_optional_regions];
>
I agree this is nicer, and I assume the memory will be associated with 
mtGC since the G1OopStarChunkedList is CHeapObj<mtGC>.

> and the corresponding delete[] in ~G1ParScanThreadState().
> 
> This would require adding ~G1OopStarChunkedList to free the chunk
> lists (possibly eliminating the need for public free_chunk_lists). It
> probably also requires giving G1OopStarChunkedList some mechanism for
> getting the "used_by_optional" information.

Yes, the public free_chunk_lists() was added for this reason, previously 
we explicitly called the destructor and had the freeing in there. Doing 
the above change I consider keeping the free_chunk_lists() method but 
moving it to the end of the optional phase, to free the memory when we 
are done with it. I also made a version b) which instead accumulate the 
used memory in an instance variable.

When doing that I realized there is a bug with the current metrics, if 
we do more than one call to evacuate_optional_regions (which can happen 
if we evac faster than predicted) we will overwrite the metrics (or 
assert in debug builds). So this fix grew a bit.

> 
> ------------------------------------------------------------------------------
> src/hotspot/share/gc/g1/heapRegion.hpp
>   253   // The index in the optional regions array, if this region
>   254   // is considered optional during a mixed collections.
>   255   uint _index_in_opt_cset;
>   256   int  _young_index_in_cset;
> 
> It's surprising (and somewhat disturbing) that the type of the new
> _index_in_opt_cset different from the type of the pre-existing
> _young_index_in_cset. It seems to be correct, but unpleasant. I'm
> guessing you get fewer annoying casts in the new code by doing it this
> way? (With UINT_MAX as the "undefined" value.) I wonder if
> _young_index_in_cset would benefit from similar treatment. Maybe an
> RFE?
Yes, something needs to be done here, my preferred way (I think) would 
be to merge the two. I looked a bit at this but there are some problems 
with that. I will file an RFE once everybody is fine with this change 
going in as is.

> 
> ------------------------------------------------------------------------------
> 



More information about the hotspot-gc-dev mailing list