RFR: 8230109: G1DirtyCardQueueSet should use card counts rather than buffer counts

[Stefan Johansson]

> 26 aug. 2019 kl. 22:48 skrev Kim Barrett <kim.barrett at oracle.com>:
> 
>> On Aug 26, 2019, at 2:29 PM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
>> 
>> 
>> 
>>> 26 aug. 2019 kl. 17:42 skrev Kim Barrett <kim.barrett at oracle.com>:
>>> 
>>>> On Aug 26, 2019, at 4:52 AM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
>>>>> 
>>>>> CR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8230109
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~kbarrett/8230109/open.00/
>>>> 
>>>> I really like the cleanups you’ve done in this area of the code base and this one is no exception. Looks good, just one question around the different G1ConcRefinement-flags (threshold and zones). Couldn’t we make these be number of cards and get rid of the buffers_to_cards conversion in g1ConcurrentRefine.cpp?
>>> 
>>> Those are product options; changing their semantics like that is not so easy.
>>> 
>> 
>> True, but I think it is something we want to do in the longer run so maybe creating an enhancement for it to track it?
> 
> Maybe, and maybe not.
> 
> If expressed in card counts, some of these numbers probably ought to
> have minimum values that are some multiple of the buffer size (which
> is also controlled by a CLA, G1UpdateBufferSize).  Having the external
> value be in buffers, internally scaled by the buffer size, might have
> usability benefits.  And suggesting or encouraging apparently higher
> precision by having options in card counts isn't necessarily useful.
> 
> Also, some of those options might go away entirely.  I did some
> experimental work a while ago on improving the adaptive controllers in
> this area, which I want to get back to.  Some of those options were no
> longer relevant or even interfering with that work.
> 
> To make such a change would involve adding new options that have card
> units (and probably have worse / longer names than the existing names
> that are already a mouthful).  I'd probably want to be experimental
> because of the above mentioned possibility of elimination or other
> changes.  Deprecate the old buffer-based options.  Add code to reject
> explicit use of both.  Retain the new code to convert buffer options
> to card units.  Somewhere down the road remove the deprecated options,
> and perhaps upgrade to product the new options; or not, if some go
> away entirely.
> 
> So I'd prefer they were left alone until such time as we have a better
> understanding of what we actually want / need here.
> 
Sounds like a good plan, and let’s hope we can figure out some good names :)