Open Bug 1025085 Opened 10 years ago Updated 1 year ago

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


(Core :: JavaScript Engine, defect)





(Reporter: till, Unassigned)


(Blocks 1 open bug)


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

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.

Whiteboard: [Shumway][Games][MemShrink] → [Shumway][Games][MemShrink:P2]
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: general → nobody
No longer blocks: shumway-m4
Whiteboard: [Shumway][Games][MemShrink:P2] → [Games][MemShrink:P2]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.