[jsc-dev] Revisiting inlining and bytecode size

[Yusuke SUZUKI]

Hi, JSC folks!

Recently I found that JSC does not work well in some microbenchmarks.
https://arewefastyet.com/#machine=29&view=single&suite=six-speed&subtest=for-of-object-es6

It shows that the critical function is not inlined.
However, seeing the actual code, I think the target function is rather very
small and we should inline that function in this case.
The focused function is "next" in the following code.

var data = {'a': 'b', 'c': 'd'};
data[Symbol.iterator] = function() {
 var array = Object.keys(data),
     nextIndex = 0;

 return {
   next: function() {
      return nextIndex < array.length ?
        {value: data[array[nextIndex++]], done: false} :
        {done: true};
   }
 };
};

function fn() {
 var ret = '';
 for (var value of data) {
   ret += value;
 }
 return ret;
}

assertEqual(fn(), 'bd');
test(fn);

In the above code, next() function looks up multiple closure variables.
nextIndex, array, and data.
In that case, our bytecode compiler emits resolve_scope and get_from_scope.
The problem is that the bytecode size of the resolve_scope and
get_from_scope is quite big... It has much metadata to optimize them well.

I think this size of these bytecodes does not reflect the actual cost of
inlining. It has much size. But actual operation in DFG / FTL is quite,
*quite* small.

So here, I would like to start discussion about whether the bytecode size
is good for cost calcucation for inlining. How do you think of accumulating
number of operations instead of instruction size?

BTW, get_by_id / put_by_id / etc. property operations also have massive
sizes. It tends to become larger over years (for metadata). But we did not
change inlining threshold.

Best regards,
Yusuke Suzuki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/jsc-dev/attachments/20170522/376e2847/attachment.html>