On Fri, Jan 27, 2017 at 8:55 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > Is there something that explains a little more what gains this will buy us > or how it will be used at the DOM level?
The best link I think is Bill's Quantum DOM blog post: https://billmccloskey.wordpress.com/2016/10/27/mozillas-quantum-project/ This post focuses on cooperative multithreading, whereas now we'd like to get to the point of having preemptive multithreading. From the engine's perspective much of the reorganization is necessary with either approach though. > What will these multiple threads actually be doing, running script from a > single webpage? No, we need to preserve run-to-completion semantics for JS, so JS scripts that can communicate with each other will end up being in the same zone group and will not be able to execute on different threads. More precisely, we'll have one zone group for each DocGroup (or maybe TabGroup, I'm not sure) on the DOM side, per the definitions in this link: https://wiki.mozilla.org/Quantum/DOM > How frequent will locking be, and what will locking overhead do to > performance? Will there ever be shared access to JS object/object graph that > requires thread locking? Since threads have exclusive access to the contents of the zone group they are operating on, there shouldn't be much need for explicit locking. Brian _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
