Issue #20022 has been updated by kjtsanaktsidis (KJ Tsanaktsidis). I stared at this and did a bit of `printf` on it, and I _think_ I worked out that the formula for how many pages to add in one heap actually relates to how many objects there are in all the other heaps, even if they're not moved. Here's my working... Let us have two size pools, `P0` and `P1`. Let `P0` have slot size `S0`, and `P1` have slot size `S1`. Let the page size be `Z` bytes. Let us start with the heap of `P0` in the following configuration: HEAP START (sweep cursor starts here) (`F0` free pages) (`N` pages of objects which want to be moved to `P1`, totaling `N * (Z/S0)` objects) (`M0` pages of objects which want to remain in `P0`, totaling `M0 * (Z/S0)` objects) HEAP END (compact cursor starts here) And with `P1` in the following configuration: HEAP START (sweep cursor starts here) (`F1` free pages) (`M1` pages of objects which want to remain in `P1`, totaling `M1 * (Z/S1)` objects) HEAP END (compact cursor starts here) Let `M1 < M0`. Now, consider what happens to the loop in `gc_sweep_compact` as we compact this heap. The objective is to work out what values for `F0` and `F1` are required such that the sweep & compact cursors do not meet until all objects have been moved to their desired size pool. For the first `M1` iterations of the loop, we are copying objects only within the two size pools. - For `P0`, the compact cursor will advance by `M1` (number of iterations), and the sweep cursor will advance by `M1` (all objects are moved within the pool, and the newly-filled pages are swept). - For `P1`, the compact cursor will advance by `M1`, and the sweep cursor will advance by `M1` (by the same logic). For the subsequent `(M0 - M1)` loop iterations, we still need to copy objects within `P0`. `P1`, however will simply be compacting empty pages with nothing in it. - For `P0`, the compact cursor will advance by `(M0 - M1)`, and the sweep cursor will advance by `(M0 - M1)` (by the same logic as the previous iterations) - For `P1`, the compact cursor will advance by `(M0 - M1)` (since it iterates too), but the sweep cursor will not advance at all (no objects are being copied into free pages in `P1`). For the next `N` iterations, the compaction loop will be copying objects out of `P0` and into `P1` when compacting `P0`, and doing nothing again when compacting `P1`. - For `P0`, the compact cursor will advance by `N` (number of iterations), and the sweep cursor will not advance at all (no pages are being filled in `P0`). - For `P1`, the compact cursor will advance by `N`, and the sweep cursor will advance by `((S1/S0) * N)` (we are copying `N` objects into new pages in `P1`, and their size changes from `S0` to `S1`, so they occupy a different number of pages). Thus, during the process: - `P0` will have had its compact cursor advance by `M1 + (M0 - M1) + N == M0 + N`, and its sweep cursor advance by `M1 + (M0 - M1) == M0` - `P0` will have had its compact cursor advance by `M1 + (M0 - M1) + N == M0 + N`, and its sweep cursor advance by `M1 + (S1/S0)*N` And so, the correct number of free pages `F0` and `F1` which need to be in `P0` and `P1` for the cursors not to meet is: * `F0 == (M0 + N) + (M0) == 2*M0 + N` * `F1 == (M0 + N) + (M1 + (S1/S0)*N) == M0 + M1 + (1 + (S1/S0)) * N` --- I have to have a think about how to generalize this to arbitrary heap layouts and five size pools - anyway figured I'd show my working as I go through it :P ---------------------------------------- Bug #20022: GC.verify_compaction_references does not actually move all objects https://bugs.ruby-lang.org/issues/20022#change-105510 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- While debugging https://bugs.ruby-lang.org/issues/20021, I ran into a separate issue which I figured was worth resolving whilst I had it in my head. The intention of GC.verify_compaction_references is, I believe, to force every single movable object to be moved, so that it's possible to debug native extensions which not correctly updating their references to objects they mark as movable (if this is _not_ the case, you can stop reading now and accept my apologies!) To do this, it doubles the number of allocated pages for each size pool, and sorts the heap pages so that the free ones are swept first; thus, every object in an old page should be moved into a free slot in one of the new pages. This worked fine until movement of objects between size pools during compaction was implemented. That causes some problems for verify_compaction_references: - We were doubling the number of pages in each size pool, but actually if some objects need to move into a different pool, there's no guarantee that they'll be enough room in that one. - It's possible for the sweep & compact cursors to meet in one size pool before all the objects that want to move into that size pool from another are processed by the compaction. You can see these problems by changing some of the movement tests in test_gc_compact.rb to try and move e.g. 50,000 objects instead of 500 (by changing `HASH_COUNT`); the test is not able to actually move all of the objects in a single compaction run. What I implemented in this PR (https://github.com/ruby/ruby/pull/9041) is two things: - Firstly, it examines every object and determine where it wants to be compacted into; we use this information to calculate the desired number of pages to add to each size pool. - Secondly, it compacts twice; once in order of ascending size pool, and once descending. This means that we are guaranteed to be able to move everything we want to move into a size pool before we start advancing that pool's own compact cursor. With these fixes in place, I was able to make the compaction tests move any amount of objects (previously, `test_moving_hashes_down_size_pools` would begin failing on my machine if I set `HASH_COUNT` to above about 6,000. -- https://bugs.ruby-lang.org/