[jsc-dev] Revisiting inlining and bytecode size

[Mark Lam]

> On May 22, 2017, at 9:07 AM, Geoffrey Garen <ggaren at apple.com> wrote:
> 
> If we want to solve the very specific problem that metadata (i.e., bytes per instruction) for certain instructions precludes inlining, then Yusuke’s suggestion — count instructions instead of bytes — is the most direct solution. FWIW, I like this solution and I don’t see any downside to it.
> 
> I like the idea of solving the metadata problem directly before moving on to other potential improvements in inlining, since it enables us to test solutions in isolation.
> 
> We’ll need some way to translate our existing size-based limits to count-based limits. I guess we could run a bunch of benchmarks and compute the average relationship between size and count. We’ll need to test any inlining change on macOS and iOS, since we’ve seen that some more aggressive inlining heuristics help macOS and hurt iOS.
> 
>> I had thought about this problem a while ago and it always seemed to me that we should, at least, change our inlining heuristic to
>> use the average DFG/FTL assembly size of the function from previous compilations when choosing to inline or not. Something like:
> 
> One downside to this approach is that it only weighs the cost of memory footprint, and not the cost of compilation time. A function may produce a large graph that ultimately gets optimized to nothing, but is very expensive to optimize. We don’t necessarily want to inline that function, since its compilation cost is high. Instruction count is a pretty good predictor of graph size and therefore compilation cost. (Or we could just record graph size directly.)

We can just as easily assign a “cost” value to each bytecode in a table, and tally up the total cost in the codeBlock at bytecode generation time.  Instruction count is a first approximation of this cost, at 1 “cost” unit per instruction.  Then we can further tweak the cost values for each bytecode instruction based on further need / evidence.

Mark


> On the other hand, perhaps the top tier should be allowed to inline without regard to compilation cost.
> 
> Geoff
> _______________________________________________
> jsc-dev mailing list
> jsc-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/jsc-dev