Refactor the interpreter loop to avoid performance degradation.

[aardvark179]

Extract function calls handling to a separate method to reduce the overall interpretLoop size.

While doing some benchmarking I noticed that the recent change to introduce super had caused a significant performance regression in the interpreter, which appears to be a result of the interpretLoop just getting too big for the JIT to do much with. This PR introduces paramterization to the benchmarks so that we test interpreted mode as well as compiled, and refactors the interpreter loop to extract the function call handling code.

This change appears to restore performance and get some small gains in the interpreter acrosss all benchmarks compared to a8696c7 (the commit immediately preceding the super implementation.

Merry Christmas everyone!

[aardvark179]

For reference when run under the interpreter the V8 Richards benchmark looked like this before the super implementation:

Benchmark                    Mode  Cnt      Score    Error  Units
V8Benchmark.richards         avgt   20  12636.684 ± 23.466  us/op

After the change it looked like this:

Benchmark                    Mode  Cnt      Score     Error  Units
V8Benchmark.richards         avgt   20  60186.535 ± 986.924  us/op

And with the refactor it now looks like this:

Benchmark                    Mode  Cnt     Score    Error  Units
V8Benchmark.richards         avgt   20  9442.805 ± 25.955  us/op

These measurements were taken before I had properly parametrised the tests, hence they lack an (Interpreted) column in the output.

[rbri]

Wow, super intresting, will try this with htmlunt

[gbrail]

I think that this is low-risk and fixes a regression and I think that we should adopt it for 1.8.0.

I wonder what other big hairy messes we have in the codebase that would benefit from a similar optimization? The "BodyCodegen" path doesn't get called as often but it's similarly awfully large!

[gbrail]

Thanks -- this is very helpful!