RFR (S): 8227719: G1 pending cards estimation too conservative for cost prediction

[Kim Barrett]

> On Jul 19, 2019, at 10:15 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi Kim,
> 
>  thanks for your thoughts on this.
> 
> On Thu, 2019-07-18 at 19:05 -0400, Kim Barrett wrote:
>>> On Jul 18, 2019, at 4:33 PM, Thomas Schatzl <
>>> thomas.schatzl at oracle.com> wrote:
>>> 
>>> [...]
>> 
>> I suggested keeping completed_buffers_num() for now, using a
>> definition of ceiling(card_count / buffer_size()), to reduce the
>> fanout of the change to internally carry around card counts rather
>> than buffer counts.  I can deal with followup on that as part of
>> working on improving DCQS and refinement thread control, which I
>> think I'm finally ready to start working on again, now that my
>> PtrQueue[Set] refactoring work seems to be approaching completion.
>> 
>> 
>> I would prefer to only be managing one counter rather than two,
>> especially as I start looking at mitigations for the DCQS lock.
>> 
> 
> New webrev at
> 
> http://cr.openjdk.java.net/~tschatzl/8227719/webrev.0_to_1 (diff)
> http://cr.openjdk.java.net/~tschatzl/8227719/webrev.1 (full)
> 
> which removes the buffer count, and replaces the
> "completed_buffers_num" method with what you suggested.
> 
> I did some very cursory perf testing with no differences.
> 
> Thanks,
>  Thomas

Looks good.

I don't think I would have renamed completed_buffers_num at this
point, but I can understand why one might find that name annoying...
(Someday I will do something about process_completed_buffers.)

One minor item, for which I don't need a new webrev.

------------------------------------------------------------------------------
src/hotspot/share/gc/g1/g1RedirtyCardsQueue.cpp
 115 void G1RedirtyCardsQueueSet::verify_empty() const {

Removed assertion on _count / _entry_count.  Should reinstate.

------------------------------------------------------------------------------