Chromium

This issue seems to be related to https://issues.chromium.org/issues/333584632

I ran the above code with BunJS. BunJS uses JavascriptCore.

while (true) {
  new WeakRef({});
}

BunJS did not crash & had stable memory usage due to Garbage Collection. NodeJS did crash after accumulating memory.

#
# Fatal error in , line 0
# Check failed: (location_) != nullptr.
#
#
#
#FailureMessage Object: 0x7fff8969b030
----- Native stack trace -----

 1: 0xd203d1  [node]
 2: 0x2118e21 V8_Fatal(char const*, ...) [node]
 3: 0x10de5fd v8::internal::Heap::KeepDuringJob(v8::internal::Handle<v8::internal::HeapObject>) [node]
 4: 0x1534381 v8::internal::Runtime_JSWeakRefAddToKeptObjects(int, unsigned long*, v8::internal::Isolate*) [node]
 5: 0x193cef6  [node]
[1]    1956898 trace trap (core dumped)  node ./tmp/oom.js

Awaiting a queueMicrotask has the same issue.

while (true) {
	new WeakRef({});
	await new Promise(resolve=>queueMicrotask(()=>resolve()));
}

Awaiting a setTimeout does not have this issue.

while (true) {
	new WeakRef({});
	await new Promise(resolve=>setTimeout(()=>resolve(), 0));
}

This is in fact the specified behavior, so V8 is working as intended to run out of memory here. It is JSC that's behaving in a non-standards compliant way.

WeakRefs are specified to be cleared only when execution returns to the event loop. The rationale in TC39 was that during synchronous execution, it is too surprising and makes reasoning about programs too difficult if WeakRefs could be cleared out from under the execution. So, only when execution returns to the event loop (that is, the JS stack becomes empty) is there an opportunity to null out WeakRefs.

The following snippet never returns to the event loop, so none of the WeakRefs are ever cleared. It infinitely loops until it runs out of memory.

while (true) {
  new WeakRef({});
}

Similarly, the following snippet also never returns to the event loop. It keeps allocating WeakRefs and Promises, but never actually returns execution to the event loop to service the setTimeout handlers.

while (true) {
	new WeakRef({});
	new Promise(resolve=>setTimeout(()=>resolve(), 0));
}

The details from the spec are:

• When a WeakRef is created or dereferenced, it calls the AddToKeptObjects AO. This adds the target to a list called [[KeptAlive]]. As long as a value is in [[KeptAlive]], it is considered live.
• The JS embedder (e.g. HTML) is supposed to call the ClearKeptObjects AO to clear that list when execution returns to the event loop.
• The HTML spec calls ClearKeptObjects when performing a microtask checkpoint. See step 6.

Sorry. I edited my comment. I was editing the benchmark & pasted in the incorrect code. I meant to paste in the following which does not seem to exit from the event loop:

while (true) {
	new WeakRef({});
	await new Promise(resolve=>queueMicrotask(()=>resolve(), 0));
}

I'm going to further research this. I think that GC behavior should be consistent whether it's on regular allocated objects or WeakRef. Meaning the least surprising behavior is if the GC acts the same for Objects or WeakRef. So if the following does not result in an OOM, neither should WeakRef:

while (true) {
  const o = {}
}

To me that would be the least surprising behavior. The spec seems like a footgun that is baffling. I cannot wrap my head around why it's done this way. It makes no sense to me.

To me that would be the least surprising behavior. The spec seems like a footgun that is baffling. I cannot wrap my head around why it's done this way. It makes no sense to me.

It's done this way because certain delegates in TC39 felt very strongly that WeakRefs be only clearable when returning to the event loop, as they thought otherwise programs would be too hard to reason about.

I can see a reasonable relaxation of the spec where if all WeakRefs containing a target themselves die within a turn, the target is removed from [[KeptAlive]]. This isn't what the spec currently says though.

Is there an issue with periodically returning to the event loop?

It's done this way because certain delegates in TC39 felt very strongly that WeakRefs be only clearable when returning to the event loop, as they thought otherwise programs would be too hard to reason about.

That's ironic b/c I find this behavior "too hard to reason about" because it is inconsistent from the rest of Javascipt.

Is there an issue with periodically returning to the event loop?

I updated the benchmarks to be asynchronous. The async benchmarks are generally slower than the synchronous benchmarks. Except when benchmarking WeakRef in a synchronous benchmark.

I'm using this behavior for a reactive memo library called rmemo. rmemo is the reactive base of an isomorphic DOM rendering library relementjs. DOM rendering libraries are expected to render synchronously. If there are > 20000 rmemos instantiated from the rendering, then there will be memory or performance issues.

I see 2 problems. WeakRef is not Garbage Collectable in the nursery. And allocating WeakRefs seems to degrade the performance of the V8 runtime. Presumably due to excessive memory allocation. Which is not present in JSC.

I benchmarked the Signals Proposal polyfill against rmemo.

The synchronous & asynchronous benchmarks seem to run faster with JSC, for all of the benchmarks.

WeakRef is not Garbage Collectable in the nursery.

Yep, that is a real shortcoming that we should fix at some point (prioritization and all that).

I'm using this behavior for a reactive memo library called rmemo. rmemo is the reactive base of an isomorphic DOM rendering library relementjs. DOM rendering libraries are expected to render synchronously. If there are > 20000 rmemos instantiated from the rendering, then there will be memory or performance issues.

In this use case, do the WeakRefs themselves also die synchronously, or just their targets?

Yep, that is a real shortcoming that we should fix at some point (prioritization and all that).

I appreciate that. I noticed that Firefox (Spider Monkey) has the same behavior. I can file an issue with them.

In this use case, do the WeakRefs themselves also die synchronously, or just their targets?

I think the WeakRefs + targets would normally be held in memory. Unless there is a synchronous operation that replaces many DOM elements. In this case:

• If there are no parent rmemos being referenced, then the WeakRef + targets will be out of scope
• If there is a parent rmemo in memory scope, holding child WeakRefs of the removed DOM elements. Then the parent rmemo holds onto the WeakRefs until it's value changes. Then the WeakRefs where deref() returns undefined are removed from the collection.

I updated the benchmark repo to include memory benchmarks. Holding 1,000,000 instances of Signals & rmemos (which has 1 WeakRef each). These instances are organized as 1000 chains of 1000 Signals/rmemos (1000 * 1000 = 1000000). The V8 runtime performed well. The rmemo benchmark used less heap memory than the Signal Polyfill. So I think I'm mistaken about the "excessive memory allocation". At least when compared to each Signal.

time node memory-rmemo.js
...
total: 1000000 {
  rss: 1152708608,
  heapTotal: 1103556608,
  heapUsed: 1060476424,
  external: 1619130,
  arrayBuffers: 10467
}
node ./memory-rmemo.js  2.59s user 0.53s system 224% cpu 1.387 total

time node memory-signal.js
...
total: 1000000 {
  rss: 1333592064,
  heapTotal: 1281544192,
  heapUsed: 1239816688,
  external: 1619130,
  arrayBuffers: 10467
}
node ./memory-signal.js  3.21s user 0.59s system 238% cpu 1.598 total

I created an issue on the Firefox bug tracker.

Yep, that is a real shortcoming that we should fix at some point (prioritization and all that).

Is this the current issue for this work? Or will it be https://issues.chromium.org/issues/333584632?

I'm hoping to demonstrate to the Firefox team that there is an active issue. This issue was switched to "Won't fix (Intended behavior)".

Is this the current issue for this work? Or will it be https://issues.chromium.org/issues/333584632?

Please file a new issue specifically for supporting WeakRefs in the young generation.

Young gen support is tracked in issue 340777103.