RFR: 8220465: Use shadow regions for faster ParallelGC full GCs

Thomas Schatzl thomas.schatzl at oracle.com
Tue Dec 3 10:39:05 UTC 2019


Hi,

On 03.12.19 10:08, Haoyu Li wrote:
> Hi Thomas,
> 
> Thanks for your reviewing. Attachments are the updated patches, and 
> details are as follows.
> 
> > I was trying to come up for a reason that "the first region cannot be a
> > shadow region", could you explain? What about if compaction starts off
> > with empty old gen? In this case probably the situation can't occur,
> > but
> > still it seems more complicated than an obviously invalid shadow region
> > id (which is far beyond the heap).
> >
> > Please change to use the ~0 sentinel (with a properly named constant)
> > instead - this is much easier to reason about than otherwise.
> 
> 
> Sorry for the oversimple explanation. The first region cannot be a 
> shadow region because we collect empty regions between max(top, new_top) 
> and end of each space as shadow regions. For old space, though it could 
> be empty, its new_top would be greater than 0 unless other spaces are 
> also empty, which I think is impossible during a full GC. Therefore, 
> max(top, new_top) will be greater than 0, and we won't collect region 0 
> as a shadow region.
> 
> But I agree with you that using the ~0 sentinel is much easier to reason 
> about the case. I have replaced the 0 with ~0 
> (ParCompactionManager::InvalidShadow) in the patches to avoid the above 
> implicit logic.

Thanks, looks good.

> > - I'd prefer if the push/pop_shadow_region_mt_safe methods used a
> > MonitorLocker and a wait/notify scheme for synchronization. The pop
> > method locking the _shadow_region_monitor in the infinite loop body
> > (and
> > not doing anything else) seems problematic when there is contention
> > (if).
> 
> 
> Thanks for the helpful suggestion! I have changed the MutexLocker to the 
> MonitorLocker/wait/notify scheme. I use the timed wait because of a 
> possible deadlock situation between two GC threads popping and pushing 
 > [...]
 > (so I reorder the two if clauses in
 > ParCompactionManager::pop_shadow_region_mt_safe), and I set the time
 > to 1 ms.

Stefan and me were just discussing this issue and to use a timed wait 
too. :)

> 
> Thanks very much for all your reviewing effort. Look forward to hearing 
> from you.

Looking at the patch, a few (further) minor nits that I fixed in the 
webrevs further below:

- I rebased the change to latest code, e.g. the parameter order in 
Atomic::cmpxchg changed recently. Basically the first parameter 
(exchange_value) got moved to the third parameter.
- we prefer to access statics via the class name, i.e. 
ParCompactionManager::InvalidShadow instead of cm->InvalidShadow.
- some asserts were not updated to latest names of the states

Please take a look if these changes are correct. I started a few 
internal regression testing runs.

First, your recent changes as webrevs:
http://cr.openjdk.java.net/~tschatzl/8220465/webrev.5_to_6/ (diff)
http://cr.openjdk.java.net/~tschatzl/8220465/webrev.6/ (full)

Above changes:
http://cr.openjdk.java.net/~tschatzl/8220465/webrev.6_to_7/ (diff)
http://cr.openjdk.java.net/~tschatzl/8220465/webrev.7/ (full)

Thanks,
   Thomas



More information about the hotspot-gc-dev mailing list