RFR: 8324649: Shenandoah: refactor implementation of free set [v6]

[Kelvin Nilsen]

On Mon, 5 Feb 2024 15:29:22 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> But even before genshen changes, there were two walks through the regions.  This is because the rebuild wants to "optimize" the organization of the mutator free set and the collector free set.  Certain regions that may have been in the mutator set during previous GC will be in the collector set during the next gc, and vice versa.  We strive to arrange that each free set is "tightly packed" over a subrange of the regions, with collector free set at the high end of memory and mutator set at the lower end of memory.  With GenShen integration, we will place the old collector set above the collector set.
>
> I suppose I'll need to look through this more carefully. In the case of single gen, it still sounded to me like the "clear" really doesn't accomplish anything other than taking stuff out of the free partitions and then the `find_..` sorts them into the new free partitions, and it looked like that could be accomplished by a single walk.
> 
> If GenShen then wants to break them into two sequences with some other step in between, may be one offers the three API's: one the single-gen optimized one that avoids two walks, and the two APIs `clear` and `find_...` separately for GenShen. But it sounds like you are saying that there is a _need_ for these two walks in the case of single gen as well. Let me discuss this with you offline so I understand this better as I am probably missing something crucial here. Thanks!

In the most recent commit, I have merged the first two passes through the free set.  We no longer have a separate clear pass that precedes moving regions with available capacity into the mutator free set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1481913157