[jsc-dev] Revisiting inlining and bytecode size

[Filip Pizlo]

> On May 23, 2017, at 9:29 AM, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:
> 
> 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.

We should use statistics.  We can track, for each opcode ID, how much machine code the DFG and FTL generate on average.  We can use some kind of running average.

We can improve this, for example by:

- Using Markov chains.  Imagine using the opcode ID of the previous instruction as part of the key to look up the running average.  Probably, the previous opcode ID predicts somewhat whether the next opcode will be cheap or expensive.

- Using profiling.  At the time that we make inlining decisions, we have access to some CodeBlock and usually a bunch of profiling data.  We can use that profling data as input to the running averages.  For example, op_add’s that have a profile that says that it never took slow path and always returned int could have a separate running average from the rest.  For get_by_id’s, we could have separate running averages for different kinds of StructureStubInfos.  The ones that say that we have a monomorphic access to self or proto can have a separate running average.

- Probably other stuff.

> 
> 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.

I propose JetStream, ARES-6, and Speedometer.

We can split them into two sets - for example we could use JetStream for tuning and then ARES-6 and Speedometer for final confirmation.  Or we can use them all for tuning.  I prefer just using them all for tuning.

> 
> Anyway, I think it's worth trying. And we should compare the result with the current approach.