Parallel JavaScript: exception throwing vs. sequential fallback When a parallel method such as mapPar is called with an elemental function that prevents parallelization, for example by writing to a global, we can either throw an exception or fall back to sequential execution. The current TC39 POR is to throw an exception. I think falling back to sequential execution is the better alternative. To maintain temporal immutability and determinism the exception needs to be thrown before any global state is altered. This implies that that the elemental (callback) function needs to be instrumented to prevent writing to non-local variables before even being run once. Some JITs execute a few iterations using an interpreter in order to do gather type information. Instrumenting this code to throw before global state is modified comes at not only a performance hit but also will imposes considerable reworking of the JIT infrastructure for it to be reused to do the instrumenting. This is potentially a heavy implementation burden. The second problem is that throwing an exception prior to modifying global state will also complicates a JavaScript implementation of a sequential polyfill since such a polyfill would have to instrument the elemental function. Given that closures can easily hide aspects of code that needs to be instrumented such a polyfill is unlikely to be possible. On the other hand falling back to a sequential implementation avoids both of these problems. If and when a write to a global is detected falling back to sequential code would be straightforward. The Interpreter/JIT could run the first few iterations sequentially, checkpoint where it is in the sequential iteration space, JIT the code, including any instrumentation that is needed, run the code concurrently, and if a write to a global is detected then fall back to the checkpoint and resume sequential iterations. The semantics of Parallel JavaScript make maintaining such a checkpoint trivial. We should revisit the decision to throw an exception in light of these implementation issues and change to semantics that allow a sequential schedule to be a legal scheduling for any elemental function whether it is temporally immutable or not. - Rick
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
