RFR: 8214278: Cleanup process_completed_threshold and related state

Kim Barrett kim.barrett at oracle.com
Mon Nov 26 21:46:24 UTC 2018

> On Nov 26, 2018, at 7:43 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> On Sun, 2018-11-25 at 20:44 -0500, Kim Barrett wrote:
>> […]
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8214278
>> https://bugs.openjdk.java.net/browse/JDK-8156696
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8214278/open.00/
>> Testing:
>> mach5 tier1-5
> Thanks for doing this cleanup.
> Some minor nits:
> - in DirtyCardQueueSet::concatenate_logs() a SizeTFlagSetting could be
> used to do the temporarily-change-value dance. (I know, the class is
> very specifically named).

I’d forgotten about those.  I keep thinking they are just for the CLA options,
but I see they are more generally applicable, and used as such in a few places.

> - not sure if static consts like
> _process_completed_buffers_threshold_never should be named like a
> member. I think at some point we agreed on (but did not write down) to
> use CamelCase for those.

See reply to StefanJ.

> Just mentioning: another option than doing the overflow check in
> PtrQueueSet::process_or_enqueue_complete_buffer could be limiting
> _completed_buffers_padding to something like INT_MAX as we already do
> for _max_completed_buffers.
> But I think the existing check is less noise than changing the padding
> code.

I looked at that, but decided the overflow check is simpler.  I’d probably need
to add some assertions on the ranges to process_or_enqueue_complete_buffer
if the restricted range approach were to be taken.

More information about the hotspot-gc-dev mailing list