This one actually seems fair to me. They're not saying that GC won't kick in on the value the deleted property used to point to, but rather that using `delete`

This one actually seems fair to me. They're not saying that GC won't kick in on the value the deleted property used to point to, but rather that using `delete` on a property can be more expensive than you need if you're just trying to let the GC know something can be cleaned up. This is because optimized JIT code and caches guard on the structure of objects that pass through them, and changing that structure (eg. deleting a property) will lead to deoptimizations / tossing away some of that code. On SpiderMonkey, deleting a property that isn't the last one that was defined may incur a "dictionary mode" conversion [0]. This means the information describing each object property, which is usually immutable and shared between similar objects, will be copied one-by-one into a unique chain owned by the particular object instance. This can only happen once per object instance, however, and subsequent usages of `delete` on its properties will be less expensive -- but still more expensive than simply setting property values to `null`. I believe something similar happens with V8's "hidden classes" mechanism. [0] https://dxr.mozilla.org/mozilla-central/source/js/src/vm/Shape.cpp#961-970 https://dxr.mozilla.org/mozilla-central/source/js/src/vm/Sha...