From:  Steve Fink <sfink@mozilla.com>
Date:  26 Jan 2017 02:16:58 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:  63.245.214.181

On 01/25/2017 03:23 AM, Nicolas B. Pierron wrote:
> Thanks for this email, and these investigations.
>
> On 01/25/2017 05:47 AM, Steve Fink wrote:
>> [what is slower in Fx vs Chrome]>>    - 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.

Sorry, I didn't meant to imply that eliminating bailouts is at all a 
good idea. I understand those reasons. But it *is* a natural reaction to 
seeing the current profiler output -- the only information it gives is a 
list of bailouts, and the very name implies something bad. And most 
importantly, when people are looking for stuff within their control to 
fix, it is bailouts are an obvious target -- since it's possible to 
change the JS code to make things single-typed, people are going to kill 
themselves trying to do that because it makes all those scary bailouts 
go away. (And then they'll be pissed off because their code runs slower.)

So bailout counts *are* a good example of a naive suggestion that will 
come up over and over again when people start looking at performance 
problems. Which implies to me that we need to give them a better metric 
to focus on. Repeated bailouts, or compiles that ended up not being 
worth it, or something.