On Fri, Jan 27, 2017 at 3:56 PM, Ehsan Akhgari
> On 2017-01-27 11:24 AM, Brian Hackett wrote:
> > On Fri, Jan 27, 2017 at 8:55 AM, Benjamin Smedberg
> > wrote:
> >> Is there something that explains a little more what gains this will buy
> >> 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.
> Actually running these threads concurrently is a non-goal for Quantum DOM.
I think I had misunderstood your original proposal Brian, I didn't realize
it's about actually running JS concurrently within the same runtime. My
brain has been too much focused on Quantum DOM these days. :-)
It seems that the ability to run JS on the SpiderMonkey side in parallel
could be useful. On the Gecko side we'd probably initially want to lock
between the Gecko/SM boundary (because everything in Gecko right now is
unsafe to be accessed across multiple threads) but then we will have a path
towards trying to measure for example which locks around calls from SM into
natives are expensive in real usage and try to parallelize things there,
and will in general give us more options on the Gecko side on
So while this isn't part of what Quantum DOM is currently focusing on I
think it will be very cool to have and by the time either sides are more
concrete we can probably explore further improvement ideas. I'm excited to
see how this effort pans out!
Thanks and sorry if my previous message came across so negatively!