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

[sangheon.kim at oracle.com]

Hi Thomas,

On 7/22/19 1:41 AM, Thomas Schatzl wrote:
> 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)
webrev.2 looks good.

Thanks,
Sangheon


>
> Thanks,
>    Thomas
>
>