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
I think it's a little bizarre for this to be part of the standard, but if it
weren't there, I wouldn't know it was safe to do this.
Differential Revision: https://phabricator.services.mozilla.com/D14511
--HG--
extra : moz-landing-system : lando
ExecutableAllocator.py's PoolIterator is a Python 3 iterator in that
it defines the __next__ method. Defining |next| as well lets this
code work in Python 2.
MozReview-Commit-ID: JlkSsZHZkpw
Differential Revision: https://phabricator.services.mozilla.com/D16500
--HG--
extra : moz-landing-system : lando
I think it's a little bizarre for this to be part of the standard, but if it
weren't there, I wouldn't know it was safe to do this.
Differential Revision: https://phabricator.services.mozilla.com/D14511
--HG--
extra : moz-landing-system : lando
Bug 1464869 resulted in blank lines being inserted between comments
and the classes they describe in the gdb unwinder code. This patch
changes most of these comments into doc strings instead.
MozReview-Commit-ID: 6XQwheUNRxI
Differential Revision: https://phabricator.services.mozilla.com/D7174
--HG--
extra : moz-landing-system : lando
No change in behavior that I'm aware of. It should be correct either way,
since the object is guaranteed to be an object created just so by code
elsewhere in the Streams implementation. But the intended purpose of
GetPropertyPure is in a fast path, backstopped by an actual GetProperty, not
for cases like this.
Differential Revision: https://phabricator.services.mozilla.com/D14505
--HG--
extra : moz-landing-system : lando
I don't know why it's OK to drop this particular error; my guess is that the
error was already reported previously, when the stream became errored, and
there's no point reporting it again.
Differential Revision: https://phabricator.services.mozilla.com/D14496
--HG--
extra : moz-landing-system : lando
Because we only ever run one subconfigure, the machinery to execute
several is not useful anymore. Inlining it allows to simplify the code
too, because it doesn't need to be generic anymore. This also removes
the last remaining bits of acwinpaths.m4.
Also remove now unused support for --list in build/subconfigure.py.
Depends on D16380
Differential Revision: https://phabricator.services.mozilla.com/D16381
--HG--
extra : moz-landing-system : lando
Because the .xdata format on ARM64 can only encode sizes up to 1M (much too small for our JIT code regions), we register a function table callback to provide RUNTIME_FUNCTIONs at runtime. Windows doesn't seem to care about the size fields on RUNTIME_FUNCTIONs that are created in this way, so the same RUNTIME_FUNCTION can work for any address in the region. We'll set up a generic one in RegisterExecutableMemory and the callback can just return a pointer to it.
Differential Revision: https://phabricator.services.mozilla.com/D16261
--HG--
extra : moz-landing-system : lando
