1122908 - Debugger statements make functions much slower

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

I just tried an x86 emulator written in JS [0], and I get the following instructions-per-second after it finishes startup and shows the red "popup":

Chrome:  ~5.3 million
Nightly: ~3.7 million

The problem is that we spend a lot of time constructing arguments objects due to the presence of debugger statements in some hot functions. I think it uses those debugger statements as a kind of assertion failure on paths that shouldn't be reached usually.

If I comment out the pc->sc->setBindingsAccessedDynamically() and funbox->setDefinitelyNeedsArgsObj() in Parser.cpp for debugger statements, we're way faster and I get 6-7 million instructions per second.

It'd be nice to not deoptimize as much, especially if the debugger is disabled.

[0] http://jemul8.com/

Comment 1

[Jan de Mooij [:jandem]]

And FWIW, Firefox 34 gets ~2.8 million. Ion-compiling JSOP_DEBUGGER (bug 1098696) probably helped a lot, it's great to see the debugger performance work pay off :)

Requiring an arguments object if "debugger;" is present is the main issue now, would be great if we could fix that too.

Comment 2

[Shu-yu Guo [:shu]]

(In reply to Jan de Mooij [:jandem] from comment #1)
> And FWIW, Firefox 34 gets ~2.8 million. Ion-compiling JSOP_DEBUGGER (bug
> 1098696) probably helped a lot, it's great to see the debugger performance
> work pay off :)
> 
> Requiring an arguments object if "debugger;" is present is the main issue
> now, would be great if we could fix that too.

Do you mean no longer give the special treatment to "debugger;" statements? As far as the arguments objects go, since *no* arguments in non-strict mode can be optimized away anyways (lol Function.arguments), creating unexpected arguments objects most of the time probably doesn't even lose any information. The removal of setBindingsAccessedDynamically() though is very likely to lose information. I would've expected CallObject creation to be just as bad as the ArgumentsObject creation.

FWIW special treatment of "debugger;" in the frontend always felt off to me, but I figured it was rare enough to not really care.

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Jan de Mooij [:jandem] from comment #1)
> Requiring an arguments object if "debugger;" is present is the main issue
> now, would be great if we could fix that too.

Why do we have such requirement, is this to avoid the cost of bailout/invalidation while running under ion?

Comment 4

[Shu-yu Guo [:shu]]

(In reply to Nicolas B. Pierron [:nbp] from comment #3)
> (In reply to Jan de Mooij [:jandem] from comment #1)
> > Requiring an arguments object if "debugger;" is present is the main issue
> > now, would be great if we could fix that too.
> 
> Why do we have such requirement, is this to avoid the cost of
> bailout/invalidation while running under ion?

I think "debugger;" has always triggered "deoptimize everything". Not sure if there's a deeper reason.

Comment 5

[Shu-yu Guo [:shu]]

(perhaps once upon a time, we couldn't readily create unexpected arguments objects for the Debugger?)

Comment 6

[Jan de Mooij [:jandem]]

(In reply to Shu-yu Guo [:shu] from comment #2)
> The removal of setBindingsAccessedDynamically() though is very
> likely to lose information. I would've expected CallObject creation to be
> just as bad as the ArgumentsObject creation.

ArgumentsObject creation is worse because Ion doesn't inline it. We could fix that of course, but ArgumentsObject also requires a malloc call for its ArgumentsData. (Would be nice if we could allocate it in the nursery eventually, like external elements/slots).