Currently SATBMarkQueueSet provides both the number of completed buffers in the list (completed_buffers_num) and a sticky flag (process_completed_buffers) that is set when the number exceeds a (configurable) threshold and cleared when the list is emptied.

G1 only directly uses the buffer count in assertions.

G1 uses the flag to decide whether there are enough completed buffers to be worth resuming marking (exit termination) in order to process some.

Shenandoah does not use the flag at all.

Shenandoah uses the count to decide whether to call apply_closure_to_completed_buffer (whose result it ignores). It could just call the apply function and pay attention to the result, and not use the count at all.

The G1 behavior could leave a lot of marking work in the qset, to be processed during the remark pause. It might be better to always resume marking if there are any buffers to process. Though care is needed for the interaction between disabled filtering (JDK-8079167) and this decision; if the mutator is generating completed buffers because filtering is turned off then marking will keep exiting the termination protocol and resuming. (This problem already exists with a non-zero processing threshold, and is just exacerbated by eliminating that threshold.)