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

[Y. Srinivas Ramakrishna]

On Sat, 3 Feb 2024 15:44:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We walk twice, first to figure out how much memory is available, and how many regions are completely empty.  This information eventually feeds into GenShen's transfer of regions between young-gen and old-gen.  There is less motivation for that distinction in single-generation Shenandoah because we do not need to make these informed transfers.
>
> 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!

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

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