RFR: 8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset [v3]

[Yude Lin]

On Wed, 26 Jan 2022 04:44:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

>> Can I have review on this small change that skips some unnecessary work in cset choosing?
>> 
>> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.
>
> Yude Lin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

The original code also use new_garbage instead of cur_garbage in the line

if ((new_garbage < min_garbage) || (r->garbage() > garbage_threshold)) {

It puzzles me. There is a slight chance that GC prefers to recycle region with less garbage than more garbage
due to this. I'm not sure that's what we want. As an example:

Suppose we have regions sorted by garbage:

region_garbage=[800k, 700k, 600k, 100k]

And suppose min_garbage=2000k, garbage_threshold=600k

The algorithm will add the 800k region and the 700k region to the cset, then it skips the 600k region,
because now new_garbage=800+700+600>2000 and it will not pass the if check above. However, it will
continue the iteration and add the 100k region to the cset. Why do we do that? As long as the max_cset
condition is satisfied, the more garbage the merrier right? Should we change ``new_garbage`` to ``cur_garbage``?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7211