Garbage collection is contrarian

Summary

Previously on this blog I've written about how Nova JavaScript engine models garbage collection using the Rust borrow checker and how to work with it, I've rambled about how I came up with the model, and I've written about the philosophical underpinnings of garbage collection in general. Most importantly I have, together with a lot of contributors, written a JavaScript engine encompassing more than 100,000 lines of Rust using this model which is equal parts excellent and awful. It is excellent in that it manages to explain garbage collected handles in such a way that the borrow checker can check that unrooted handles are not kept on stack past garbage collection safepoints, but it is awful in how it achieves this, turning code into a soup of let handle = handle.bind(nogc) and handle.unbind() calls. A Norwegian university employee said of the system just last month: "That's worse than C++." This entire time, I've been working with this model with the assumption that it is the correct way to model garbage collection, and that the manual aspects and some limitations of it are simply caused by limitations of the Rust borrow checker. Much of this changed last weekend because I was writing a safety comment to explain a very contrarian limitation of the system. Working with a garbage collected heap A garbage collected system always has some heap structure wherein it stores the garbage collected data. The heap will then contain garbage collected handles, ie. self-references. Let's consider a singular handle Handle<'_, T> stored on the heap and try to figure out what is the correct lifetime that we should ascribe to '_. Because this is a garbage collected system, as long as this Handle<'_, T> exists on the heap (and is itself reachable from some root) then the T is kept alive as well. It is incorrect for the Handle to be alive but the T to be dead, but once the Handle is dropped by the garbage collector it is also free to drop the T. This also applies to moving the T: concep...