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

[Thomas Schatzl]

Hi Kim,

On Sat, 2019-07-20 at 22:03 -0400, Kim Barrett wrote:
> > On Jul 19, 2019, at 6:42 PM, Kim Barrett <kim.barrett at oracle.com>
> > wrote:
> > 
> > > On Jul 19, 2019, at 10:15 AM, Thomas Schatzl <
> > > thomas.schatzl at oracle.com> wrote:
> > > 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.
> 
> Oops, I realized later that I missed something.
> 
> -------------------------------------------------------------------
> -----------
> src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
>  156     return align_up(num_entries_in_completed_buffers(),
> buffer_size()) / buffer_size();
> 
> align_up requires the alignment value to be a power of 2, but the
> buffer size is not required to be a power of 2, so this doesn't work.
> It just so happens that the default buffer_size *is* a power of 2
> (G1UpdateBufferSize defaults to 256), and we probably don't have any
> tests that use a non-default buffer_size.
> 
> 

Oops.

http://cr.openjdk.java.net/~tschatzl/8227719/webrev.1_to_2 (diff)
http://cr.openjdk.java.net/~tschatzl/8227719/webrev.2 (full)

Thanks,
  Thomas