682477 - Reduce backedge code cloning in Interpret()

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

With the last m-c to TI merge Interpret() has gotten a little too big, and Linux x86 OPT is now OOMing on tinderbox.  The gcc non-DEBUG preprocessed version of Interpret is 236KB on m-c, 332KB on TI (there's some cruft in these, and inlining is not considered, but these should correlate at least somewhat with compilation complexity).  About 2/3 of the difference is due to new logic when calling the method JIT on back edges.  The backedge logic is copied in 11 places in Interpret(), and each copy is 5KB of preprocessed code on m-c and 10KB on TI (52/113 KB total).  There's no fundamental reason for this cloning, and these could be collated into a single copy.  This seems preferable to trying to turn the backedge logic into a separate (non-inline) function, as the logic uses a bunch of the interpreter locals and goto labels.

Comment 1

[Luke Wagner [:luke]]

!!!
We should get a plaque or something.

Comment 2

[Brian Hackett [Laid off!]]

Attachment: patch

Patch.  I see no perf change for -j, -m -j -p, nor -m -n on SS.  Times for 'make jsinterp.o' in an x86 OPT build:

TI (old): 1m18s
TI (new): 35s
m-c: 45s

Comment 3

[Brian Hackett [Laid off!]]

http://hg.mozilla.org/projects/jaegermonkey/rev/53e56c928ead

Comment 4

[Jan de Mooij [:jandem]]

(In reply to Brian Hackett from comment #0)
> and Linux x86 OPT is now OOMing on tinderbox.

For the last month(s), my Mac has been swapping like crazy when compiling jsinterp in release mode (it has 4GB). Really annoying, even with -j1 it took ages. I thought it was some 10.7 or GCC-without-LLVM problem. Glad to see this fixed.

Comment 5

[Dan Gohman [:sunfish]]

The patch was checked in, so this was fixed. Also, the TM code has been removed since then.