[webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

[Zoltan Herczeg]

https://bugs.webkit.org/show_bug.cgi?id=63531

The work was done by Zoltan Horvath and Balazs Kelemen.

Regards,
Zoltan

> Hi Zoltan,
>
> I would be curious how you did the synchronization.  I've had some luck
> reducing synchronization costs before.
>
> Was the patch ever uploaded anywhere?
>
> -F
>
>
> On Jan 10, 2013, at 12:11 AM, Zoltan Herczeg <zherczeg at webkit.org> wrote:
>
>> Parsing, especially JS parsing still takes a large amount of time on
>> page
>> loading. We tried to improve the preload scanner by moving it into
>> anouther thread, but there was no gain (except some special cases).
>> Synchronization between threads is surprisingly (ridiculously) costly,
>> usually worth for those tasks, which needs quite a few million
>> instructions to be executed (and tokenization takes far less in most
>> cases). For smaller tasks, SIMD instruction sets can help, which is
>> basically a parallel execution on a single thread. Anyway it is worth
>> trying, but it is really challenging to make it work in practice. Good
>> luck!
>>
>> Regards,
>> Zoltan
>>
>>> On Jan 9, 2013, at 10:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>>> On Wed, 9 Jan 2013, Eric Seidel wrote:
>>>>>
>>>>> The core goal is to reduce latency -- to free up the main thread for
>>>>> JavaScript and UI interaction -- which as you correctly note, cannot
>>>>> be
>>>>> moved off of the main thread due to the "single thread of execution"
>>>>> model of the web.
>>>>
>>>> Parsing and (maybe to a lesser extent) compiling JS can be moved off
>>>> the
>>>> main thread, though, right? That's probably worth examining too, if it
>>>> hasn't already been done.
>>>
>>> 100% agree.
>>>
>>> However, the same problem I brought up about tokenization applies here:
>>> a
>>> lot of JS functions are super cheap to parse and compile already, and
>>> the
>>> latency of doing so on the main thread is likely to be lower than the
>>> latency of chatting with another core.  I suspect this could be
>>> alleviated
>>> by (1) aggressively pipelining the work, where during page load or
>>> during
>>> heavy JS use the compilation thread always has a non-empty queue of
>>> work
>>> to do; this will mean that the latency of communication is paid only
>>> when
>>> the first compilation occurs, and (2) allowing the main thread to steal
>>> work from the compilation queue.  I'm not sure how to make (2) work
>>> well.
>>> For parsing it's actually harder since we rely heavily on the lazy
>>> parsing
>>> optimization: code is only parsed once we need it *right now* to run a
>>> function.  For compilation, it's somewhat easier: the most expensive
>>> compilation step is the third-tier optimizing JIT; we can delay this as
>>> long as we want, though the longer we dela
>>> y it, the longer we spend running slower code.
>>>
>>> Hence, to make parsing concurrent, the main problem is figuring out how
>>> to
>>> do predictive parsing: have a concurrent thread start parsing something
>>> just before we need it.  Without predictive parsing, making it
>>> concurrent
>>> would be a guaranteed loss since the main thread would just be stuck
>>> waiting for the thread to finish.
>>>
>>> To make optimized compiles concurrent without a regression, the main
>>> problem is ensuring that in those cases where we believe that the time
>>> taken to compile the function will be smaller than the time taken to
>>> awake
>>> the concurrent thread, we will instead just compile it on the main
>>> thread
>>> right away.  Though, if we could predict that a function was going to
>>> get
>>> hot in the future, we could speculatively tell a concurrent thread to
>>> compile it fully knowing that it won't wake up and do so until exactly
>>> when we would have otherwise invoked the compiler on the main thread
>>> (that
>>> is, it'll wake up and start compiling it once the main thread has
>>> executed
>>> the function enough times to get good profiling data).
>>>
>>> Anyway, you're absolutely right that this is an area that should be
>>> explored.
>>>
>>> -F
>>>
>>>
>>>>
>>>> --
>>>> Ian Hickson               U+1047E                )\._.,--....,'``.
>>>> fL
>>>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
>>>> ,.
>>>> Things that are impossible just take longer.
>>>> `._.-(,_..'--(,_..'`-.;.'
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>