W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

From: Marc Fawzi <marc.fawzi@gmail.com>
Date: Thu, 2 Apr 2015 08:22:18 -0700
Message-ID: <CACioZivsd1+5Qyck09aGYty+enfma6pzP2Npa7Z4bLp8YD41Hw@mail.gmail.com>
To: Brendan Eich <brendan@secure.meer.net>
Cc: Travis Leithead <travis.leithead@microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Michaela Merz <michaela.merz@hermetos.com>, Florian Bösch <pyalot@gmail.com>, Glenn Adams <glenn@skynav.com>, Ashley Gullen <ashley@scirra.com>, George Calvert <george.calvert@loudthink.com>
Boom!

http://pixelscommander.com/en/web-applications-performance/render-html-css-in-webgl-to-get-highest-performance-possibl/

This looks pretty amazing.

On Sat, Feb 14, 2015 at 4:01 PM, Brendan Eich <brendan@secure.meer.net>
wrote:

> Hang on a sec before going off to a private or single-vendor thread
> because you think I sent you packing on topics that are of interest (as
> opposed to "Thread-Safe DOM").
>
> I'm sorry I missed Travis's mail in my Inbox, but I see it now in the
> archives. The topics listed at the link he cites *are* interesting to many
> folks here, even if public-webapps may not always be the best list:
>
> -----
>
> IRC log: http://www.w3.org/2014/10/29-parallel-irc
>
> See also: Mohammad (Moh) Reza Haghighat's presentation on parallelism in
> the 29 October 2014 Anniversary Symposium talks
>
> We covered three main potential areas for parallelism:
>
> 1. Find additional isolated areas of the web platform to enable
> parallelism. We noted Canvas Contexts that can migrate to workers to enable
> parallelism. Initial thoughts around UIWorkers are brewing for handling
> scrolling effects. Audio Workers are already being developed with specific
> real-time requirements. What additional features can be made faster by
> moving them off to workers?
>
> 2. "Shared memory" models. This seems to require an investment in the
> JavaScript object primitives to enable multiple threaded access to object
> dictionaries that offer robust protections around multi-write scenarios for
> properties.
>
> 3. Isolation boundaries for DOM access. We realized we needed to find an
> appropriate place to provide isolation such that DOM accesses could be
> "assigned" to a parallelizable JS engine. Based on discussion it sounded
> like element sub-trees wouldn't be possible to isolate, but that documents
> might be. Iframes of different origins may already be parallelized in some
> browsers.
>
>
> -----
>
> Mozilla people have done work in all three areas, collaborating with Intel
> and Google people at least. Ongoing work continues as far as I know. Again,
> some of it may be better done in groups other than public-webapps. I cited
> roc's blog post about custom view scrolling, which seems to fall under
> Travis's (1) above.
>
> Please don't feel rejected about any of these work items.
>
> /be
>
>
>
>  Marc Fawzi <mailto:marc.fawzi@gmail.com>
>> February 13, 2015 at 12:45 PM
>> Travis,
>>
>> That would be awesome.
>>
>> I will go over that link and hopefully have starting points for the
>> discussion.
>>
>> My day job actually allows me to dedicate time to experimentation (hence
>> the ClojureScript stuff), so if you have any private branches of IE with
>> latest DOM experiments, I'd be very happy to explore any new potential or
>> new efficiency that your ideas may give us! I'm very keen on that, too.
>>
>> Off list seems to be best here..
>>
>> Thank you Travis. I really appreciate being able to communicate freely
>> about ideas.
>>
>> Marc
>>
>>
>> Boris Zbarsky <mailto:bzbarsky@mit.edu>
>> February 11, 2015 at 12:33 PM
>> On 2/11/15 3:04 PM, Brendan Eich wrote:
>>
>>> If you want multi-threaded DOM access, then again based on all that I
>>> know about the three open source browser engines in the field, I do not
>>> see any implementor taking the huge bug-risk and opportunity-cost and
>>> (mainly) performance-regression hit of adding barriers and other
>>> synchronization devices all over their DOM code. Only the Servo project,
>>> which is all about safety with maximal hardware parallelism, might get
>>> to the promised land you seek (even that's not clear yet).
>>>
>>
>> A good start is defining terms.  What do we mean by "multi-threaded DOM
>> access"?
>>
>> If we mean "concurrent access to the same DOM objects from both a window
>> and a worker, or multiple workers", then I think that's a no-go in Servo as
>> well, and not worth trying to design for: it would introduce a lot of spec
>> and implementation complexity that I don't think is warranted by the use
>> cases I've seen.
>>
>> If we mean the much more modest "have a DOM implementation available in
>> workers" then that might be viable.  Even _that_ is pretty hard to do in
>> Gecko, at least, because there is various global state (caches of various
>> sorts) that the DOM uses that would need to either move into TLS or become
>> threadsafe in some form or something...  Again, various specs (mostly DOM
>> and HTML) would need to be gone over very carefully to make sure they're
>> not making assumptions about the availability of such global shared state.
>>
>>  We should add lighter-weight workers and immutable data structures
>>>
>>
>> I should note that even some things that could be immutable might
>> involved a shared cache in current implementations (e.g. to speed up
>> sequential indexed access into a child list implemented as a linked
>> list)...  Obviously that sort of thing can be changed, but your bigger
>> point that there is a lot of risk to doing that in existing implementations
>> remains.
>>
>> -Boris
>>
>> Brendan Eich <mailto:brendan@secure.meer.net>
>> February 11, 2015 at 12:04 PM
>>
>>
>> Sorry, I was too grumpy -- my apologies.
>>
>> I don't see much ground for progress in this whole thread or the
>> sub-thread you started.
>>
>> If we're talking about sync XHR, I gave my informed opinion that
>> deprecating it is empty talk if actually obsoleting by whichever browser
>> takes the first hit inevitably leads to market share loss or (before that)
>> developers screaming enough to get the CEO's attention. We will simply
>> waste a lot of time and energy (we already are) arguing and hollering for
>> and against deprecation, without any definite hope of obsolescence.
>>
>> If you want multi-threaded DOM access, then again based on all that I
>> know about the three open source browser engines in the field, I do not see
>> any implementor taking the huge bug-risk and opportunity-cost and (mainly)
>> performance-regression hit of adding barriers and other synchronization
>> devices all over their DOM code. Only the Servo project, which is all about
>> safety with maximal hardware parallelism, might get to the promised land
>> you seek (even that's not clear yet).
>>
>> Doing "over the top" JS libraries/toolchains such as React is excellent,
>> I support it. But it does not share mutable or immutable state across
>> threads. JS is still single-threaded, event loop concurrency with mutable
>> state, in its execution model. This execution model was born and co-evolved
>> with the DOM 20 years ago (I'm to blame). It can't be changed
>> backward-compatibly and no one will break the Web.
>>
>> We should add lighter-weight workers and immutable data structures and
>> other such things, and these are on the "Harmony" agenda with the JS
>> standards body. We might even find race-confined ways to run asm.js code on
>> multiple workers with shared memory in an ArrayBuffer -- that's an area of
>> active research. But none of these things is anything near to what you
>> described in the forked subject line: "Thread-Safe DOM".
>>
>> I'll leave it at this.I invite others from Mozilla, Google, Apple, and MS
>> to speak up if they disagree.
>>
>> /be
>>
>>
Received on Thursday, 2 April 2015 15:23:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC