Bug 313787 – Promise resolvers keep the Promise alive even after resolution

• Status: NEW
• Component: JavaScriptCore

[Kevin Gibbons]

Created attachment 479406 [details]
repro showing high heap usage even after GC

Once a Promise has resolved, its resolvers become no-ops and should not prevent the Promise from being gc'd, but they do. This is most noticeable when using Promise.race to race a long-pending and a short-pending Promise: the race completes quickly with the value from the short-pending Promise, which is then kept alive until the long-pending Promise completes, because the long-pending Promise holds a resolver for the Promise.race Promise and this bug causes that to keep said Promise alive.

V8 has the same bug which I am in the process of fixing. SpiderMonkey does not. This has been plaguing developers for years, see e.g. https://github.com/nodejs/node/issues/17469 https://x.com/KentonVarda/status/2044935325554823193 etc

I am pretty sure all that's necessary to fix this is to null out the `JSFunctionWithFields::Field::ResolvingPromise` field on both `callee` and `other` immediate after this bit: https://github.com/WebKit/WebKit/blob/013da9aa8cc1a0e26f5f34408efa118956499193/Source/JavaScriptCore/runtime/JSPromise.cpp#L418-L421

but I haven't actually confirmed that.

Attachment uses Bun because it exposes the APIs necessary to make this obvious, sorry I don't have a cleaner repro.

[Radar WebKit Bug Importer]

<rdar://problem/176061996>