RFR: 8214278: Cleanup process_completed_threshold and related state
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:
>> 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
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