On Sat, Mar 20, 2021 at 7:40 PM Stephen R. van den Berg srb@cuci.nl wrote:
Can you (or anyone) explain how the GC uses this variable to detect those? I'm guessing that the GC only works with svalues, not with plain objects?
That is precisely why it needs to be mapped, otherwise the GC cycle checks can't see it. If it is mapped, it will (presumably) be picked up by real_gc_cycle_check_object(), among possibly other places. You removed the map, the GC won't see it now, and that's a regression.
By the way, do you have any examples for when
commit 7def00d27ac7a31be123aaf7b63299d612d5802c Author: Stephen R. van den Berg srb@cuci.nl Date: Mon Mar 15 00:27:52 2021 +0100
Stdio.Buffer: Do not optimise the buffer to empty if there are subbuffers.
would cause any
"generic data corruption bugs"? As far as I could see having a quick glance, all changes to the data and/or allocation should be guarded by io_add_space() (and thus result in io_add_space_do_something() throwing an error via io_ensure_unlocked()), thus even if ->len and ->offset are set to zero, no changes to data or allocation should occur. Maybe you actually did notice corruption in Shuffler instead?