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

Stefan Johansson stefan.johansson at oracle.com
Tue Aug 27 07:34:50 UTC 2019

> 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 :)

More information about the hotspot-gc-dev mailing list