-
KJ Tsanaktsidis authored
There seems to be another manifestation of bug #20021, where some of the compaction tests are failing on i686 for unrelated PR's because of fake "live" references to moved objects on the machine stack. We _could_ solve this by counting how many objects are pinned during compaction, but doing that involves pushing down the mark & pin bitset merge into gc_compact_plane and out of gc_compact_page, which I thought was pretty ugly. Now that we've solved bug #20022 though, we're able to compact arbitrarily many objects with GC.verify_compaction_references, so the number of objects we're moving is now 50,000 instead of 500. Since that's now much larger than the number of objects likely to be pinned, I think it's safe enough to just add a fudge-factor to the tests. Any _other_ change in GC.verify_compaction_references that breaks compaction is now highly likely to break the assertion by more than 10 objects, since it's operating on so many more in the first place. [Bug #20021]
KJ Tsanaktsidis authoredThere seems to be another manifestation of bug #20021, where some of the compaction tests are failing on i686 for unrelated PR's because of fake "live" references to moved objects on the machine stack. We _could_ solve this by counting how many objects are pinned during compaction, but doing that involves pushing down the mark & pin bitset merge into gc_compact_plane and out of gc_compact_page, which I thought was pretty ugly. Now that we've solved bug #20022 though, we're able to compact arbitrarily many objects with GC.verify_compaction_references, so the number of objects we're moving is now 50,000 instead of 500. Since that's now much larger than the number of objects likely to be pinned, I think it's safe enough to just add a fudge-factor to the tests. Any _other_ change in GC.verify_compaction_references that breaks compaction is now highly likely to break the assertion by more than 10 objects, since it's operating on so many more in the first place. [Bug #20021]
Loading