Currently Bug 900784 only encode the bytecode when using the off-main-thread parser. One of the side effects is that we miss the opportunity to encode the bytecode of many scripts which are only on the main thread, which is the most common case on tp5n benchmark. Doing so will also help to create a separated heuristics for the bytecode cache recording than the one which is only based on the script size, as done today. To do so, we have to change the nsJSUtils CompileAndExec function to return a JSScript (and all functions below it) and share the existing code for triggering the encoding of the bytecode.

This patch does multiple things: 1/ ExecutionContext: Cleans-up the way we trigger the encoding of the bytecode from the ExecutionContext methods. It does so by adding a flag which calls the incremental encoder, or not, based on the value of the flag. Thus, merging JoinEncodeAndExec with JoinAndExec. 2/ ExecutionContext::CompileAndExec: It replaces the use of JS::Evaluate by JS::Compile / JS::CompileForNonSyntacticScope and JS_Execute call, in order to insert a call to StartIncrementalEncoding in between without having to patch every functions in between. (Bug 1364120 comment 3) (see also http://logs.glob.uno/?c=mozilla%23jsapi&s=18+May+2017&e=18+May+2017#c844709) 3/ ScriptLoader::EvaluateScript: Move the encoding part out of the off-main-thread (JoinAndExec) parsing branch, in order to share it with the main-thread (CompileAndExec) branch. Extract the location of the upcoming heuristic for the bytecode cache, which at the moment consists of the Eager flag. (mCacheInfo is always nullptr if the bytecode cache is disabled)

Pushed by npierron@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/930b86eafc2c Encode JS bytecode of scripts which are parsed on the main thread. r=mrbkap