Some additional information:

The issue doesn't happen if the result buffer is not posted to the worker.

Also attached the output of $ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --no-sandbox --disable-extensions --disable-plugins --js-flags="--trace_gc --trace_gc_verbose" http://localhost:6931/index.html as gc_trace.log

And tried forcing GC after postMessage() which completely eliminated the memory expansion, logs in force_gc.log. External memory is reported around ~2GB but Activity Monitor reports constant ~1GB, difference is because of non-committed pages?

I suspect this is connected to TypedArrays using external memory and scavenge vs. mark-and-sweep heuristics, but I'm not familiar with V8's GC.

Deleted: gc_trace.log 38.8 KB

gc_trace.log 38.8 KB View Download

Deleted: force_gc.log 4.2 KB

force_gc.log 4.2 KB View Download

This test case is allocating C-heap memory with each postMessage call, because the typed array in the message is being copied. This memory is only reclaimed when garbage collection occurs on the worker's JavaScript context.

The correct way to implement a producer-consumer queue with a web worker that uses a bounded amount of memory is to transfer an ArrayBuffer from the main thread to the worker (using the postMessage(message, [transferables]) form -- see https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage ), and transfer it back from the worker to the main thread for refilling using another postMessage call. A double-buffering technique can be used so that the main thread always has a buffer ready to fill.

I'm closing this as WontFix. The primitives exist in the platform to avoid unbounded memory consumption in cases like this.

Sure, the mentioned technique would be the best way, and that's what I wanted to use originally, but IE doesn't have Transferable and if possible we wanted to avoid platform specifics in our architecture if possible. Also Firefox doesn't show this behaviour.

I expected the C-heap memory to be deallocated much earlier as it's not referenced in the worker after the onmessage callback finishes, so it's not purely unbounded memory consumption. How come that the memory grows so much and no collection runs?

We're currently reworking the way c memory is handled, see issue 621829

But in general, I agree with Ken: there's an API for that

Yeah I found this issue, will keep an eye on it, thanks.

In theory I do agree as well, in practice it's not just black and white; as said we have to support every major browser and they behave differently (as expected?).

We will implement specific paths for using Transferables, but hope this issue will be fixed in the future with the mentioned rework.