If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Support copy-on-write for ArrayBuffers copied between (DOM Worker) threads

NEW
Unassigned

Status

()

Core
JavaScript Engine
3 years ago
3 years ago

People

(Reporter: till, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Games][MemShrink:P2])

(Reporter)

Description

3 years ago
It's not currently possible to share even read-only buffers between workers and the main thread (or other workers).

Ideally, we wouldn't (need to) add explicit support for something like this to the platform. If we supported COW for them, it would happen implicitly.

I'm pretty sure that this would be interesting for various other use cases in games and maybe PDF.js, too, but here's the scenario I'm most interested in:

Shumway is transitioning to a model where all ActionScript execution happens in a worker thread, while rendering happens on the main thread. For pretty much all vector shapes, we need to have the full path data available in both the worker and the main thread: for hit testing in the former and rasterization in the latter. These buffers aren't ever written to on the main thread, and almost never on the worker thread after having been copied, so they would be perfect candidates for COW.

Then there are bitmaps, which can be written into and read from synchronously in ActionScript, and which we obviously also need on the main thread. Here, COW might actually enter the picture, but in the vast majority of cases, we just have two never-written-to copies of the data lying around.

Additionally, tc39 plans to add explicit neutering of ArrayBuffers to the language[1]. With that, we'd have even more sharing potential: after executing one of Flash's frame updates, we collect all resulting differences in the display list in a buffer and send that over to the main thread, which updates the rendering accordingly. I'd expect that in many cases, rendering is finished before we start serializing the next frame. If we were to neuter the buffer on the main thread (which, again, never writes to it) once we don't need it anymore, the same buffer could be reused in the worker without any issues.

All in all, I'm pretty sure we would save substantial amounts of memory in normal operation.

I'm making this depend on bug 934450 because I assume that would be a good first step. Please remove if the situation is totally different for ArrayBuffers.


[1]: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-06/jun-4.md#48-arraybuffer-neutering
Whiteboard: [Shumway][Games][MemShrink] → [Shumway][Games][MemShrink:P2]
Blocks: 1037580
Blocks: 1038982
(Reporter)

Comment 1

3 years ago
This would be very nice to have, but it doesn't block bug 1038982 at all. In fact I kinda doubt we'll ever get copy-on-write buffers between processes, but who knows.
No longer blocks: 1038982
(Assignee)

Updated

3 years ago
Assignee: general → nobody
(Reporter)

Updated

3 years ago
No longer blocks: 1037580
Whiteboard: [Shumway][Games][MemShrink:P2] → [Games][MemShrink:P2]
You need to log in before you can comment on or make changes to this bug.