Bug 53485 – Web Workers' shared memory

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebCore Misc.

[Gabor Loki]

The Web Workers are very good feature, for example if a heavy computation is needed in JavaScript, or there is a need to manage shared data through different sessions. Although the current specification and design of Web Workers is robust, the communication interface is based on a message-passing method. This communication channel is not efficient if a large chunk of data have to be moved through the message-passing channel of Web Workers.

One possible solution could be to use a shared memory region for this kind of data passing. If there is shared memory region which is accessible from the main and the worker threads, there will be no need to use the message-passing channel for large data. This will save cpu resources (like converting the raw data for message-passing channel). The peak memory consumption will not be increased because of this method, although the minimal memory consumption will be bigger (with the size of shared memory region of course).

[Gabor Loki]

Created attachment 80742 [details]
proof of concept shared memory

I have a patch which shows a proof of concept shared memory feature for workers. The patch is not complete, but it shows what we can achieve with shared memory. I am going to attach an simple example which shows the performance differences between the message-passing and shared memory communication. My measurement was that the communication with shared memory more than 20-30 times faster on x86 and on ARM as well.

The current patch has the following features:

 * create a worker with shared memory

   // create a worker where the 'size_of_shared_memory' is the size of shared memory region in bytes.
   new Worker("worker-file-name.js", size_of_shared_memory);

 * access the shared memory from the main and the worker thread

   // fill the shared memory from the 'initial_pos' offset
   // with the content of 'uint32Array' which is an Uint32Array
   worker.setUint32Array(initial_pos, uint32Array);

   // create an Uint32Array which contains 'number_of_elements' elements
   // from the 'initial_pos' offset of shared memory
   var array = worker.getUint32Array(initial_pos, number_of_elements);
   

Well, as I said this is a proof of concept patch. So, I have a list of issues, which should be addressed before landing. If anyone is interested in this topic and wants get involved, please share your thoughts! I would really appreciate it ;)

Here is my todo list:
 * add more get/set methods for shared memory region (such as getUint8Array, etc).
 * if the workers live in processes, we should use the shared memory of the host system as a shared memory region for workers.
 * design a common class/structure which can be passed to the workers from the main process for both thread- and process-based workers.
 * ensure Shared Web Workers work as expected.
 * propose as an extension for the standard of Web Workers at W3C ;)

What is your thoughts about the concept of workers' shared memory?

[Gabor Loki]

Created attachment 80743 [details]
Example main page for workers' shared memory

[Gabor Loki]

Created attachment 80744 [details]
Example worker for workers' shared memory

[Alexey Proskuryakov]

To use shared memory, you also need synchronization primitives, such as mutexes and condition variables. It's a primary design principle of web workers that the complexities of doing proper multithreaded design will not be exposed to JavaScript developers.

There is a definitive need for faster ways to pass data to workers and back, but adding explicit shared state is not an acceptable direction. I'll go as far as WONTFIX this bug, although discussion of various ideas on speeding things up is certainly welcome.

-#if ENABLE(WEBGL) || ENABLE(BLOB)
+#if ENABLE(ARRAYBUFFERS)

This change has been discussed on webkit-dev recently. I'm not sure if there was a specific outcome - some people were unhappy about adding more feature defines. It clearly needs to be in a separate bug/patch though.