631740 - Investigate using the interpreter to avoid JM compilation overhead

Status: RESOLVED DUPLICATE of bug 631951

(Core :: JavaScript Engine, defect)

Description

[Chris Leary [:cdleary] (not checking bugmail)]

The idea that the team has is to cull out part of the call graph that are not invoked enough times or run for long enough to warrant the compilation speed/space overhead. I wrote a patch to transition from the interpreter to method-JIT-compilation. ( http://hg.mozilla.org/users/cleary_mozilla.com/tm-interp-mq/ )

It's parameterized, per JSScript, on two values: the number of taken back-edges observed for that script and the number of JSOP_CALL-based invocations of that script.  N.B. Method JIT call inline caches continue to try to compile callees as they were.

Bill and I investigated on SunSpider performance today and found the farthest we could push these knobs without really regressing our sunspider score was to (4096 calls before compilation, 512 back edges before compilation).

I just built a browser that tracks total (accumulated) mjit allocation space, including IC stub generation, until the destruction of the runtime, and we're going to be experimenting with speed/space comparisons there.

Comment 1

[Chris Leary [:cdleary] (not checking bugmail)]

Attachment: Matches up with plot 2, shows points with acceptable SunSpider scores.

Comment 2

[Chris Leary [:cdleary] (not checking bugmail)]

Attachment: Data points as (calls before compilation, back edges before compilation).

A value of -1 indicates that a method will never be compiled for this reason, whereas a value of 0 indicates that a method will be compiled the very first time this reason is encountered.

Comment 3

[Nicholas Nethercote [inactive]]

(In reply to comment #0)
> 
> Bill and I investigated on SunSpider performance today and found the farthest
> we could push these knobs without really regressing our sunspider score was to
> (4096 calls before compilation, 512 back edges before compilation).

4096/512 is *much* more aggressive (in terms of avoiding compilation) than I was anticipating would be needed to get good space reduction, and dmandelin's figures in bug 631581 agree, IIUC.  Great news!

Comment 4

[Chris Leary [:cdleary] (not checking bugmail)]

(In reply to comment #3)

Thanks for that background info too -- I had missed that comment earlier.

Just to emphasize: we picked the "fringe" numbers and we don't know how benchmark-specific (4096, 512) are to SunSpider.

Comment 5

[Nicholas Nethercote [inactive]]

(In reply to comment #4)
> 
> Just to emphasize: we picked the "fringe" numbers and we don't know how
> benchmark-specific (4096, 512) are to SunSpider.

Sure.  I had been thinking 10 would be a good starting point for measurements :)

Comment 6

[Nicholas Nethercote [inactive]]

(In reply to comment #0)
> The idea that the team has is to cull out part of the call graph that are not
> invoked enough times or run for long enough to warrant the compilation
> speed/space overhead. I wrote a patch to transition from the interpreter to
> method-JIT-compilation. (
> http://hg.mozilla.org/users/cleary_mozilla.com/tm-interp-mq/ )

Just to clarify:  dmandelin proposed two possible don't-compile-everything approaches in bug 631706 and bug 631714, with the latter being more aggressive.  I think your measurements correspond to the latter -- is that right?

Comment 7

[Brendan Eich [:brendan]]

Please don't tune for the stupid benchmarks only. Of course, you have to avoid regressing them. Life in the big city.

/be