In #13528 the behavior of the incremental GC of the copying collector was changed to synchronously finish the collection (sometimes at least) on drop. As commented in that PR this is required for correctness w.r.t. the GC (and to fix fuzzers at the time), but this behvaior means that a host may still suffer GC pauses despite the incrementality. For example a host that times out a module will still perform synchronous work once the timeout causes the host future to get dropped.
Ideally this would be fixed somehow insofar as the units of incrementality in the GC wouldn't ever force synchronous execution. As Nick points out, though, doing this would be quite difficult. The hardest problem perhaps is that when the GC is half-done then reads of GC pointers are not currently allowed, and we've got not realistic way to prevent that. Perhaps one day with a concurrent GC this would be more tractable, but in the meantime I mostly want to be sure to log this in an issue.
In #13528 the behavior of the incremental GC of the copying collector was changed to synchronously finish the collection (sometimes at least) on drop. As commented in that PR this is required for correctness w.r.t. the GC (and to fix fuzzers at the time), but this behvaior means that a host may still suffer GC pauses despite the incrementality. For example a host that times out a module will still perform synchronous work once the timeout causes the host future to get dropped.
Ideally this would be fixed somehow insofar as the units of incrementality in the GC wouldn't ever force synchronous execution. As Nick points out, though, doing this would be quite difficult. The hardest problem perhaps is that when the GC is half-done then reads of GC pointers are not currently allowed, and we've got not realistic way to prevent that. Perhaps one day with a concurrent GC this would be more tractable, but in the meantime I mostly want to be sure to log this in an issue.