Will Blink Introduce DOMJIT Technique?

[林作健]

Hi,

   I just have a glimpse at WebKit's implementation of DOMJIT. It is a module make custom getter/setter a code generator, which generates native code to get the attribute of a impl object.

   Is blink planning to do something like this?

[nehte...@gmail.com]

[Kentaro Hara]

The short answer is no.

One year ago Blink tried to implement Fast DOM Accessor (see this Intent-to-implement), which is actually DOM-JIT. However, after prototyping it, we learned that 1) it improves only Dromaeo and micro-benchmarks (e.g., it doesn't improve Speedometer and real-world benchmarks) and 2) it adds a bunch of intrusive APIs to V8 bindings and regresses the code health. So we decided to not ship it.

Here is another data point: Currently jbroman@, lfg@ and adithyas@ are investigating the performance of Speedometer but binding overhead of simple DOM attributes doesn't look like a main performance bottleneck. So I'm not sure how much Fast DOM Accessor / DOM-JIT can improve performance of Speedometer and the real web.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d2cace9b-0bfb-4314-8208-8eff10c6d9aa%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

[林作健]

Thanks for the answer. It makes sense.

在 2017年10月25日星期三 UTC+8下午6:15:37，Kentaro Hara写道：

[Daniel Vogelheim]

On Wed, Oct 25, 2017 at 12:15 PM, Kentaro Hara <har...@chromium.org> wrote:

The short answer is no.

One year ago Blink tried to implement Fast DOM Accessor (see this Intent-to-implement), which is actually DOM-JIT. However, after prototyping it, we learned that 1) it improves only Dromaeo and micro-benchmarks (e.g., it doesn't improve Speedometer and real-world benchmarks) and 2) it adds a bunch of intrusive APIs to V8 bindings and regresses the code health. So we decided to not ship it.

Kentaro summarized the result well.

I didn't know WebKit had tried the same. I could imagine that one could get more out of it if one were to take a more general approach (we implemented jit-ing only for simple getters that effectively read a C++ member), but if I look at WebKit's tracking bug then they seem to have looked at the exact same 5 accessors with a very similar implementation strategy. With some reading between the lines, they also got roughly similar results in that they don't mention any non-synthetic benchmark where they got an improvement.

[Chen Zhixiang]

DOM-JIT means JITed JS code to connect to DOM C++ code and C++ class layout,
but IMO, the better way is to move DOM entirely to JS prototype... that is, DOM-in-JS.
Chrome previously had promoted that, but sadly no following news