We should be able to specify an understandable subset of JS that will successfully execute in parallel, possibly after some (finite) number of sequential executions that are used to gather type information prior to jit compilation. This is partly true today, but not quite, because there are a number of places where we rely on TI information in order to ensure that a given path is threadsafe. For example, calling math functions like `Math.abs` or `Math.sin` currently only works when we are able to inline the call. It should always work even if inlining is not possible (for example, because there is a megamorphic call site where we can't precict the receiver). I took a stab at defining what I think is a reasonable subset (as well as a subset that is within reach) in this blog post: http://smallcultfollowing.com/babysteps/blog/2013/04/30/parallelizable-javascript-subset/ Obviously, we need a more formal writeup somewhere else, probably the wiki. This is a meta bug, so we should add other dependencies to other bugs for individual problems.

I couldn't find any information on this, so let me ask for a clarification on asmjs and parallel js in this bug. The initial writeup does not cover whether it should be possible to use asmjs in a parallel map. I think asmjs and parallel maps is a very natural and safe programming model and I'd like some clarity around that programming model. If, when opencl compilation fails, sequential execution is used, then there's an unfortunate performance characteristic where web workers or parallel map could be faster depending on very implementation dependent information. If a thread pool is the fallback when opencl fails, and these threads support asmjs, then the fallback isn't "sequential execution", but thread pool execution. For kernels that are large, or for large arrays, this seems like a win. So can you please clarify: will threads be used as a fallback, and will the threads support asmjs?

(In reply to alexander.kjeldaas from comment #1) At the moment, parallel JS works like this: After a sequential warmup, an attempt is made to compile the code for parallel execution; that may fail, as parallel execution requires that a kernel - the function to be run in parallel - not modify state visible to more than the one kernel. If parallel compilation is successful, parallel execution always takes place on multiple threads within a single address space / a single JS runtime instance, this would typically be a window / iframe / worker. The parallel kernel is never compiled to OpenCL / WebCL, and there are no plans to implement that that I'm aware of. At the moment, asm.js cannot be used within the parallel kernel, since parallel compilation depends on a safety analysis and compilation mode that is tied to the normal optimizing javascript compiler back-end (ionmonkey). The more likely usage mode for asm.js is with multiple DOM workers representing multiple threads, and a SharedArrayBuffer representing shared memory for those threads.

PJS has been removed from Firefox.

(In reply to Lars T Hansen [:lth] from comment #3) > PJS has been removed from Firefox. What is the bug for this removal?

Bug 1117724 - (removepjs) [meta] Remove PJS