592350 - JM: JIT code shouldn't traverse prototypes

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, enhancement)

Description

[Brian Hackett [Laid off!]]

Idea from a couple weeks ago I should have filed then.  There are several hot places where prototypes or other objects are traversed over and over, checking for properties that are extremely unlikely to ever change.

- When setting a hole in an array, the array and object prototypes are checked for indexed setters.
- When adding new properties to an object, shape guards are done for the prototype chain.
- When doing a CALLPROP, most of which are going to be accessing a prototype, a couple shape guards and lookups are done to fetch the property.
- When doing a CALLGNAME or lookup on certain global variables (e.g. Math) is done, a shape guard and lookup are done to fetch the property.

All this work is avoidable.  By keeping information on the appropriate prototype JSObjects and Shapes about what data the PICs depend on and aren't checking (tricky, since everything seems to be out of flag bits), if any of this data actually does change the PICs could be fixed by doing a GC (deoptimizing future PICs to do the checks so that future changes don't also GC).

Ideal code for:

Math.sin(x) :

check-x-is-number
push x
call math.h sin function

x.charCodeAt(y) :

check-x-is-string
check-y-is-int
check-y-in-range
fetch-character

CALLGNAME could in most cases be nop'ed

Not sure how much this would save.  I know the array-holes thing is 1ms on SS, so conservatively 5ms, 10ms more optimistically when integrated with inlining various native CALLPROPs.

Comment 1

[Brendan Eich [:brendan]]

(In reply to comment #0)
> Idea from a couple weeks ago I should have filed then.  There are several hot
> places where prototypes or other objects are traversed over and over, checking
> for properties that are extremely unlikely to ever change.
> 
> - When setting a hole in an array, the array and object prototypes are checked
> for indexed setters.

This should be optimized, indeed. It's insanely rare (or just insane) to put indexed props on built-in prototypes.

> - When adding new properties to an object, shape guards are done for the
> prototype chain.

This is bug 592153 -- the design of the property cache and shape system mean you do not need to check every shape.

> - When doing a CALLGNAME or lookup on certain global variables (e.g. Math) is
> done, a shape guard and lookup are done to fetch the property.

TM requires global shape invariance. Can JM too, for its fast paths anyway? You have to check somehow, I guess. Or as you propose, be prepared to fix up JITted code when shapes change.

> Not sure how much this would save.  I know the array-holes thing is 1ms on SS,
> so conservatively 5ms, 10ms more optimistically when integrated with inlining
> various native CALLPROPs.

Invalidating or reJITting when shapes change is possible, at some cost. We talked about it a while ago (dmandelin may have filed a bug).

Where are we out of bits that you'd need?

/be

Comment 2

[Jan de Mooij [:jandem]]

JM was removed and TI got rid of most indexed-properties checks, Math.sin CALLPROP shape checks, etc.