576733 - JM: PICs for not-escaped call objects

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

bz's test case in 576687 comment #7 is 7-8X slower in JM versus TM. We should be able to generate special-case PICs for scope chains.

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Mysteriously, something about my 32-bit TM appears to be busted on this test case. But not in debug mode.

dvander@dvander:~/mozilla/moo/js/src$ ~/mozilla/tracemonkey/js/src/Opt32/js -j k.js 
533
dvander@dvander:~/mozilla/moo/js/src$ ~/mozilla/tracemonkey/js/src/Debug32/js -j k.js 
1095
dvander@dvander:~/mozilla/moo/js/src$ ~/mozilla/tracemonkey/js/src/Opt64/js -j k.js 
5916

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: WIP v1

This patch adds a PIC for JSOP_NAME. If the property is found on a Call object, it emits a scope chain walk. Each link is tested for non-NULL and shape identity. Any links that are non-cacheable cause the PIC to be disabled.

Notes:
 * Only js_GetCallArg and js_GetCallVar are supported right now.
 * Escaped frames are not yet supported.
 * Properties found on the global are not supported.

On my machine, this brings the score from 822 to 1452 - tracing's got 6,000, so still work to do.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Remaining culprits:

[jaeger] PICs     setprop disabled: setter (k.js: 6)
[jaeger] PICs     setprop disabled: setter (k.js: 7)

This patch halves the number of NAME slow-calls in v8, which was not very many (~130k). Will investigate what the others are tomorrow.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: WIP v2

PIC for SETNAME w/ non-escaped callobj. This brings our score to 2800.

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

http://hg.mozilla.org/users/danderson_mozilla.com/moo/rev/18b8df733e33

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.  Any idea why this is still so much slower than tracing?  Fwiw, V8 and current nitro are faster than tracing on the attached testcase....

Looking at the patch, we do generate code to directly poke dslots, right?

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to comment #6)

With your test case, or the A* benchmark? For the test case, the closure doesn't escape. This patch only optimized non-escaping call objects, i.e. poke at fp->argv/slots rather than callobj->dslots.

Comment 8

[Boris Zbarsky [:bzbarsky]]

My testcase.

It looks like that testcase wasn't quite a correct reduction of dromaeo, which uses escaping Call objects.  Filed bug 576926 on those.

But in any case, even my testcase is a lot slower that TM and definitely than v8/nitro....