From:  "Nicolas B. Pierron" <nicolas.b.pierron@mozilla.com>
Date:  25 Jan 2017 19:23:59 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: Report on Google Suites work week in Taipei

NNTP-Posting-Host:  83.153.1.144

Thanks for this email, and these investigations.

On 01/25/2017 05:47 AM, Steve Fink wrote:
> [what is slower in Fx vs Chrome]
>
> […] Going further, we would like to be able to say that a
> specific script took X ms longer in Fx than in Chrome, but we don't have
> tooling for that either. […]

I know disabling inlining will damage performances of both engines, but this 
could provide a way to compare the performance results independently of the 
optimization provided through the inlining.

If we are slower, then we would have specific function to look for.
Otherwise, we would have to investigate the inlining heuristics.

> - A good description of the overall flow of the engine, as it relates to
> performance. Every time we go over this with someone new, the same ideas and
> suggestions arise.
>    -[…]
>    - eliminate all or most bailouts

I will try to explain more the details here, and hopefully help people 
understand why this is a bad idea to eliminate *all* bailouts.

When we have no bailout from a code produced by a compiler, this means that 
the compiler generated code which is infallible, and thus handle all the 
cases.  Basically, this implies that we have to handle all the cases, this 
is what our Baseline compiler do.

Bailouts are a necessary evil. They give us the opportunity to remove code 
paths which are unlikely to be used, and thus to have more optimization 
coming out of it, such as most basic one: unboxing values.

Bailouts are a JIT compiler trade-off.  They are optimization which can be 
costly to proove, bailouts are a trade-off between the time we spend in an 
all-guarantee compiler, and the time we get we a heuristic-based compiler. 
Also, a heuristic-based compiler has more opportunities to find 
optimizations can cannot be safely guaranteed.

I honestly would prefer to optimize our compiler such that we could afford 
more heuristic-based optimizations, including the trade-off of having more 
bailouts.  And, I already suggested ways to achieve that in SpiderMonkey!

Let's not follow other JS engine on this fact, there is much more 
performance opportunities to gain by embracing bailouts than refusing them.

-- 
Nicolas B. Pierron