662704 - TI: big SunSpider regression with type inference enabled

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

SunSpider 0.9.1 in-browser with type inference enabled, Windows 7:

  Jun 6 m-c nightly:   200.7
  Jun 7 TI  nightly:   388.6

Comment 1

[Boris Zbarsky [:bzbarsky]]

So TI is ok in the shell here but not in browser?

Comment 2

[Brian Hackett [Laid off!]]

Just tried SS on my mac, TI seems to have thrown off our don't-GC-during-SS heuristics and now we always get a 109ms GC during bitwise-and.  Discounting that, TI enabled is about 5ms slower than the Firefox 5 beta (haven't compared to nightly).  I imagine the problem is worse on windows, will look closer tomorrow.

Comment 3

[Brian Hackett [Laid off!]]

Some Win7 numbers I get, nightly vs. inference enabled.

Nightly

Total:                 199.4ms +/- 1.4%
    morph:               5.3ms +/- 6.5%
    bitwise-and:         1.3ms +/- 26.6%
    format-tofte:       14.0ms +/- 0.0%
    partial-sums:        8.5ms +/- 4.4%
    base64:              3.1ms +/- 7.3%
    tagcloud:           14.9ms +/- 1.5%

Inference Enabled

Total:                  349.6ms +/- 0.6%
    morph:               21.3ms +/- 2.3%
    bitwise-and:        125.7ms +/- 0.7%
    format-tofte:        17.1ms +/- 2.4%
    partial-sums:        13.3ms +/- 2.6%
    base64:               8.2ms +/- 3.7%
    tagcloud:            17.3ms +/- 2.0%

The main issue is the GC during bitwise-and.  The other tests shown here are those where numbers are significantly different from the Mac AWFY numbers.  Fixing the issues with these tests should bring us to about the same place as stock TM.

Comment 4

[David Mandelin [:dmandelin]]

I currently see this on TM.

Comment 5

[Gregor Wagner [:gwagner]]

Attachment: GCTimer output

There is a very long (333ms) GC in there that is caused by a JS_API call. It happens exactly 4 sec after the previous GC so I suspect the 4sec trigger in the CC.
The long GC spends 250ms in the END callback. That might be something to look at as well.

Comment 6

[Gregor Wagner [:gwagner]]

The GCs (marking) take longer and longer. Something may be leaking as well.

Comment 7

[Brian Hackett [Laid off!]]

Mmmm, sorry for reflexively blaming the GC (remembered the problems we had here before with GC timing in SS).  The problem here is specific to TI; the issue is that with TI enabled we never compile uncached eval scripts, which have a lifetime managed by API clients and can be destroyed at times other than on GC.  This plays havoc with the assumptions inference makes that scripts are always safe to access from type constraints, so uncached eval scripts are not analyzed.  Top level <script> tags in the browser are uncached eval scripts, unlike the global scripts in the shell; bitops-bitwise-and is basically just a long-running loop in global code, and never leaves the interpreter.

Bug 674251 should remove this restriction; all scripts have lifetimes managed by the GC, and it will be straightforward to analyze and compile uncached eval scripts.

Comment 8

[Brian Hackett [Laid off!]]

Attachment: patch

Unblock on bug 674251.  This has EvaluateUCScriptForPrincipalsCommon and EvaluateInScope give script objects to the results and let the GC destroy them instead of doing so immediately after execution.  Allows us to analyze/compile such scirpts and removes a fair bit of analysis cruft in place to account for these scripts.

This also fixes a perf bug in GNAMEINC ops where we emitted a SETPROP in the decomposed version instead of SETGNAME.  This was compiled as a normal SETPROP IC (which is safe to do here), but in the browser (not shell) this PIC ends up getting disabled --- Window objects have a class setter hook XPC_WN_Helper_SetProperty (???) which causes the ICs to bail out.

This will (I think) still cause bad browser perf for SETNAME ops which go to global objects.

Confirmed this fixes the bitwise-and regression.

http://hg.mozilla.org/projects/jaegermonkey/rev/7dae91c263cf

Comment 9

[Brian Hackett [Laid off!]]

On latest Windows nightlies for SS I get 230ms for m-c and 223ms for JM.  This is similar to AWFY performance.

Comment 10

[Andreas Gal :gal]

Similar? Can we get concrete numbers here?

Comment 11

[Brian Hackett [Laid off!]]

The latest awfy-regress page (OS X, shell, x86) is 304ms m-c, 300ms JM, so Windows browser performance is showing a slightly larger edge for JM.