Bug 162544 – [DOMJIT] Introducing DOM binding JIT

• Component: Bindings
• Status: NEW

[Yusuke Suzuki]

Some DOM operations are very tiny operation. For example, firstChild just looks up the stored member from Node*.
In these cases, DOM binding code itself occupies large part of execution time.

We would like to optimize DOM binding further by implementing DOM binding code in special IR.
And this IR will be handled in JSC DFG, and they should be correctly inlined.

[Yusuke Suzuki]

Currently I'm planning to introduce binding JIT for DOM accessors first.
In particular, first, I'm planning to implement firstChild etc. (DOM traversal) operations by hand. And later, generalizing them and producing framework to handle DOM accessors.

Why I would like to focus on DOM accessors first is,

1. DOM accessors are typically tiny.

Some DOM accessors are very tiny operations. For example, firstChild just looks up the member field of Node* (Of course, it also has type checking of `this`).
As a result, large part of operation is occupied by DOM binding code.
If DOM operation itself is heavy, DOM binding does not occupy large part of it, and benefit of DOM binding JIT becomes small.

2. We can implement whole the DOM binding logic in JIT

If a DOM operation is complex, while we can implement DOM binding code in JIT, in the middle of JIT code, we still need to call C runtime function to invoke an actual operation. This limits the benefit of DOM binding JIT.

If we can implement whole the logic in JIT code, we can inline DOM operations. And DOM accessors are good example we can easily implement it in JIT.

[Yusuke Suzuki]

To check the benefit, I'll prototype firstChild in DFG intrinsic first.
And after checking performance benefit, I'll consider the way to generalize it.
The target benchmark is Dromaeo dom-traversal.

[Yusuke Suzuki]

OK, initial plan is,

1. Introducing some intrinsic system for CustomAccessorGetter
2. Introduce some DFG node, like, DOMAttributeGet
3. Inline DOM getter into several DFG nodes. If OSRExit occurs, we just fall back to a simple custom getter function call (First, we target such a getter, no side effect).

In (3) case, maybe, we will emit nodes for firstChild such as,

1: node
2: Check(node@1, JSElementType)
3: DOMNodeFlagCheck(node@1, ContainerNode) (Or, we can introduce SpecContainerNode)
4: DOMAttributeGet(node@1, offset to firstChild) (Here, we would like to use heap prediction)

[Yusuke Suzuki]

Created attachment 290008 [details]
Prototype

WIP: Moving WebCore DOM types into JSC

[Yusuke Suzuki]

Created attachment 290058 [details]
Prototype rev2

WIP: Introduce naive DOMJIT generation. Not using it actually yet. Not considering about layering violation since this is a prototype.

[Yusuke Suzuki]

Created attachment 290063 [details]
Prototype rev3

WIP: Adding DFG path.

[Yusuke Suzuki]

Figure out the necessary operation in firstChild.

1: node
2: Check DOMNodeUse, @1
3: GetDOMWrapped @1 => OpaquePointer (We should support such a type in DFG / FTL)
4: CheckDOMNodeFlags @3, IsContainerFlag
5: GetDOMAttributeValue @3, offset, sizeof(Node*) => OpaquePointer
6: GetGlobalObject @1
7: ToDOMWrapper @6, @5, Node => JSNode

[Yusuke Suzuki]

Currently, we take super naive approach since it is a prototype. We directly use DFG::SpeculativeJIT from WebCore (That's bad).
After measuring the performance, we will introduce DOMJIT IR, like the following.

1: node
2: Check DOMNodeUse, @1
3: GetDOMWrapped @1 => OpaquePointer (We should support such a type in DFG / FTL)
4: CheckDOMNodeFlags @3, IsContainerFlag
5: GetDOMAttributeValue @3, offset, sizeof(Node*) => OpaquePointer
6: GetGlobalObject @1
7: ToDOMWrapper @6, @5, Node => JSNode

And pass the data to DFG. And DFG converts this IR to DFG Nodes.

In our first implementation, we leave C++ binding code for LLInt and Baseline. Along with it, DOMJIT attributes has the above IR data.
And when handling these attributes accesses in DFG, we will use the IR to inline it.

[Yusuke Suzuki]

Created attachment 290181 [details]
Prototype rev4

WIP: Add DOMJIT IR

[Yusuke Suzuki]

Created attachment 290184 [details]
Prototype rev5

WIP: Fix more things

[Yusuke Suzuki]

Created attachment 290215 [details]
Prototype rev6

WIP: Fix more things

[Yusuke Suzuki]

Created attachment 290245 [details]
Prototype rev7

WIP: Fix more things

[Yusuke Suzuki]

Created attachment 290357 [details]
Prototype rev8

WIP: Fix more things!

[Yusuke Suzuki]

Anyway, moving JSElementTypes into JSC would us to use these edge filters easily.
It should help if we would like to recognize type signatures in DFG and inline type checks.

[Yusuke Suzuki]

Created attachment 290482 [details]
Patch

WIP: Updating

[Yusuke Suzuki]

Created attachment 290483 [details]
Patch

WIP: Updating

[Yusuke Suzuki]

Created attachment 290496 [details]
Prototype rev9

WIP: Introduce DOMJIT::Patchpoint

[Yusuke Suzuki]

Created attachment 290567 [details]
Prototype rev10, CheckDOM becomes very effective

WIP: Introduce DOMJIT::Patchpoint

[Yusuke Suzuki]

Created attachment 290571 [details]
Prototype rev11, more clean up

WIP: Introduce DOMJIT::Patchpoint

[Yusuke Suzuki]

We will offer 2 types of DOMJIT

1. Hand written DOM inlining.

We inject DOMJIT::Patchpoint compiler into JSC. And JSC uses this to inline DOM operation, and drop type checks.
Since the operation is fully inlined, potentially it has large performance boost.
Some super stupid tiny micro benchmark (that repeatedly accesses document.body.firstChild) shows 40% improvement.
On the other hand, since we wrote it by hand, this way does not scale well.
We will apply this method to only super hot accessors like parentNode etc.

Note that CSS Selector JIT compiler already does the similar things: accessing parentNode etc. directly by using offsets.

2. Exposing signature information.

We will offer function type signature by some representation and pass it to JSC.
JSC will use to drop type checks. Since IDL code generator already knows this,
we can automatically generate such a information. Since we don't perform any inlining,
the performance boost may be limited. But it's worth doing.
For example, if you write like,

document.getElementById("...");

DFG knows,

1. argument count is 1
2. argument is definitely String
3. |this| is document object. We already emit CheckStructure when performing `document.getElementById` GetById ops!

Above 3 things effectively drop many checks of binding code.