Bug 8285 – Implement "TreeCode" based javascript interpreter

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Eric Seidel (no email)]

ggaren and I got a little carried away last weekend and well... implemented treecode.

<rdar://problem/4409156>

[Eric Seidel (no email)]

Created attachment 7610 [details]
First stab a treecode based JavaScript interpreter

First of all, this patch passes *ALL* javascript test cases, but it should not be considered a finished product.  We've come a long way, but we have a little ways left to go.
Currently the TreeCode interpreter is a little slower than TOT, however there is a lot of fat left to trim.
This patch is here to facilitate discussion, as I'm sure at least Maciej and Darin will have a number of thoughts on the issue.

[Eric Seidel (no email)]

FYI: on my MacBookPro the current numbers show nearly a 50% performance regression.  Again, there is a lot of fat left to trim.

% compare-timing-files -c 5 old.times latest-treecode.times

===== old.times =====
average of fastest 5 runs: 726.8
range of fastest 5 runs: 0.69% (5)

===== latest-treecode.times =====
average of fastest 5 runs: 1052.2
range of fastest 5 runs: 0.38% (4)

performance LOSS of 44.77% (325.4 / 726.8)

[Geoffrey Garen]

In some unit tests, the current numbers are only a 2% regression. It's likely that the js-ibench numbers reflect the fact that we haven't integrated function calls yet, so a function call starts up a nested version of the interpreter loop.

[Darin Adler]

Comment on attachment 7610 [details]
First stab a treecode based JavaScript interpreter

This is going well, on a branch. But this patch is obsolete and we won't be reviewing it.

[Cameron Zwarich (cpst)]

We did this with SquirrelFish.