[jsc-dev] Revisiting inlining and bytecode size

[Yusuke SUZUKI]

On Wed, May 24, 2017 at 2:46 AM, Filip Pizlo <fpizlo at apple.com> wrote:

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

Nice, this can be a simple first step.


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

Yes, and we should investigate existing approaches in the other VMs
including JVM.
Since inlining heuristic is a major challenge, I think we can find various
approaches in previous work.


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

Yeah, ARES-6 and Speedometer would  be nice for the target.


>
> >
> > 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/20170526/426d5415/attachment.html>