[jsc-dev] Revisiting inlining and bytecode size

[Yusuke SUZUKI]

Thank all!

Yes, as Keith said, ideally, we should calculate inlining cost based on
actual code size in DFG and FTL.
But the problem is that some code can be merged, eliminated, converted etc.
It makes the above problem a bit hard.

As Mark stated, we can annotate our bytecode with cost. This is very simple
extension. But it causes a problem that we need to precisely model inlining
cost when adding a bytecode.
This cost should be determined in some automated approach. Without any
automated approach, it introduces huge maintenance burden and we end up
tuning parameters.

So, as a simple step, I would like to explore # of opcodes approach.
Geoff's opinion is very interesting.
This solves current metadata problem well. It models inlining cost rather
than the bytes of bytecode.
And this approach avoids never-ending parameter tuning.

Of course, in addition to the above change, many threshold (inlining
threshold) should be adjusted.
As Filip said, we should pick a benchmark suite (octane?) to explore the
good threshold.

Anyway, I think it's worth trying. And we should compare the result with
the current approach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/jsc-dev/attachments/20170524/7f0917f6/attachment.html>