RFR (M): 8159422: Very high Concurrent Mark mark stack contention

Thomas Schatzl thomas.schatzl at oracle.com
Thu Aug 4 09:52:22 UTC 2016


Hi Mikael,

  thanks a lot for your review.

On Wed, 2016-08-03 at 18:05 +0200, Mikael Gerdin wrote:
> Hi Thomas,
> 
> On 2016-08-02 11:24, Thomas Schatzl wrote:
> > 
> > Hi everyone,
> > 
> >   could someone take a look at this change?
> > 
> > Its FC extension request  has already been approved too...
> > 
[...]
> > > This is an enhancement, which is waiting for final approval.
> > > 
> > > CR:
> > > https://bugs.openjdk.java.net/browse/JDK-8159422
> > > Webrev:
> > > http://cr.openjdk.java.net/~tschatzl/8159422/webrev/
> I'm not too fond of having G1CMMarkStack::_base be a void** and 
> performing all addressing arithmetic on it "by hand" vs just using a 
> OopChunk* and integer indices, hwm and capacity.
> 
> The increment of _hwm could be just an unconditional atomic increment
>  since allocate_new_chunk is the only user of that, all values of
> _hwm larger than _capacity could simply be ignored.
> 
> Perhaps MmapArrayAllocator<G1CMMarkStack::OopChunk, mtGC>::allocate 
> could be used to allocate the marking stack chunks? You could have a 
> scoped typedef for it in G1CMMarkStack to make it slightly less
> verbose.

Will fix.

> G1ConcurrentMark::note_{end,start}_of_gc are now empty, perhaps they 
> should be removed?
> 
> Would you mind making the iterate function NOT_PRODUCT_RETURN similar
> to its caller to make it more clear that it's just used for
> verification purposes?

Okay.

Thanks a lot again,
  Thomas




More information about the hotspot-gc-dev mailing list