RFR: 8214278: Cleanup process_completed_threshold and related state

[Kim Barrett]

> 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.
OK.

> - 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.