Alternative version of part 4 which does not add new telemetry.
--HG--
extra : rebase_source : fa733a8d1394e1eca4c9f43e0c8ee1c250e736a3
extra : histedit_source : fa838e0cdbaf9c287a9997a2d85f2aa773920987%2Ccbc0208c43057dc5f8424281d90a08d9265d9fbe
The code that manages the LiveSavedFrameCache would very much like to assert
that, if a frame has its hasCachedSavedFrame bit set, then it actually does have
an entry in the LiveSavedFrameCache. However, in the presence of compartment
mismatches, this becomes temporarily untrue, and OOMs can make 'temporarily'
longer than expected.
This patch more aggressively clears frames' hasCachedSavedFrame bits, so that
when we do purge the cache for a compartment mismatch, all frames get their bits
cleared before we start repopulating the cache.
Differential Revision: https://phabricator.services.mozilla.com/D16661
--HG--
extra : moz-landing-system : lando
Add a dummy change to old-configure.in so that old-configure is
force-refreshed.
Differential Revision: https://phabricator.services.mozilla.com/D16797
--HG--
extra : moz-landing-system : lando
InterpreterFrameInfo is just a very simple interface on top of masm.
CompilerFrameInfo maintains the virtual stack based on the script it's
compiling.
Differential Revision: https://phabricator.services.mozilla.com/D16480
--HG--
extra : moz-landing-system : lando
The interpreter won't use the virtual stack and StackValue, so we need to
refactor things a bit so we don't call frame.peek(x) outside the FrameInfo class.
StackValue will be just an implementation detail of CompilerFrameInfo in the
next patch.
Differential Revision: https://phabricator.services.mozilla.com/D16479
--HG--
extra : moz-landing-system : lando
We're not handling lexical variable in BinAST parser for now, and
it results in unhelpful error at the first reference.
Detecting the lexical variable at declaration and throw more helpful error.
Differential Revision: https://phabricator.services.mozilla.com/D16807
--HG--
extra : moz-landing-system : lando
JSOPs like JSOP_INT8 that depend on the pc need to be specialized now for the
interpreter. I added MOZ_CRASH versions of these that we can implement later.
This split is a bit pessimistic: we should actually (partially) share codegen
for some of these ops like JSOP_RESUME. However it's easier to revisit this
later when we need to implement these ops for the interpreter.
Differential Revision: https://phabricator.services.mozilla.com/D16442
--HG--
extra : moz-landing-system : lando
The next patch will template-specialize some of the emit_JSOP_FOO methods, but
the C++ compiler wants that to happen before we call these methods in emitBody.
Differential Revision: https://phabricator.services.mozilla.com/D16441
--HG--
extra : moz-landing-system : lando
Interpreter and compiler will implement these differently, but this allows
sharing codegen for a large number of JSOps.
Differential Revision: https://phabricator.services.mozilla.com/D16438
--HG--
extra : moz-landing-system : lando
Since js configure is also python configure, we can actually create
a ConfigureSandbox directly, with the right environment and arguments.
Depends on D16668
Differential Revision: https://phabricator.services.mozilla.com/D16669
--HG--
extra : moz-landing-system : lando
Use an I/O wrapper on the configure output handler to add the "js/src>"
prefix.
Depends on D16643
Differential Revision: https://phabricator.services.mozilla.com/D16644
--HG--
extra : moz-landing-system : lando
Instead, include the module and inline its main function.
Depends on D16622
Differential Revision: https://phabricator.services.mozilla.com/D16623
--HG--
extra : moz-landing-system : lando
This happens to remove the last use of perl from configure.
Depends on D16621
Differential Revision: https://phabricator.services.mozilla.com/D16622
--HG--
extra : moz-landing-system : lando
This simplifies LexicalEnvironmentObject::thisValue so it's easier to inline in JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D16586
--HG--
extra : moz-landing-system : lando
