The assert was overzealous and should just be removed. Other return
addresses reported by iterator are just sampled by stack and don't
indicate if stack is synced or not.
Also, fix up an out-of-date comment here.
Differential Revision: https://phabricator.services.mozilla.com/D14108
--HG--
extra : moz-landing-system : lando
This helper makes it considerably easier for C++ code to import a JS module
and wrap it in an appropriately-defined XPIDL interface for its exports.
Typical usage is something like:
Foo.jsm:
var EXPORTED_SYMBOLS = ["foo"];
function foo(bar) {
return bar.toString();
}
mozIFoo.idl:
interface mozIFoo : nsISupports {
AString foo(double meh);
}
Thing.cpp:
nsCOMPtr<mozIFoo> foo = do_ImportModule(
"resource://meh/Foo.jsm");
MOZ_TRY(foo->Foo(42));
Differential Revision: https://phabricator.services.mozilla.com/D14209
--HG--
extra : rebase_source : 4d518205b173fc210908235b42ddace590e6b7e5
Because we now set the sysroot include flags early in python configure,
we don't need to set CPP/CXXCPP. We also skip the explicit compiler test
because more complete tests follow anyways.
Differential Revision: https://phabricator.services.mozilla.com/D14380
We're always setting -dead_strip on mac builds, per
cross-mozconfig.common, we might as well not do that and revert bug
638149, which disabled adding -dead_strip with LTO: that is apparently
not a problem anymore.
Differential Revision: https://phabricator.services.mozilla.com/D14373
Move js/src/jsapi.h declarations related to promises and job queues into their
own public header file, js/public/Promise.h. Change the compilation units that
need these declarations to #include the new header.
There should be no changes to the actual functionality here, simply moving the
code to a new file, and removing the "JS" prefix from some typedefs which are
now in the JS namespace.
Differential Revision: https://phabricator.services.mozilla.com/D13345
--HG--
extra : moz-landing-system : lando
Debugger invisibility is only practical to enforce on compartment boundaries,
and for its proper uses, that's good enough. Unfortunately, at present, debugger
invisibility is a flag on realms. This misfit is the reason for the sole
remaining code that assumes that every object is associated with a particular
realm: Debugger.Object.prototype.unwrap consults the unwrapped object's global
to see whether it is about to reveal an object that it must not. We would like
to remove this code.
This patch:
- adds an `invisibleToDebugger` flag to JS::Compartment, and sets it from the
Realm options (since there is no API for creating compartments directly; only
the act of creating a Realm can create a compartment to hold it);
- changes Debugger.Object.prototype.unwrap to check the compartment's flag, thus
removing the final use of JSObject::deprecatedRealm;
- asserts that new realms added to a compartment have a compatible visibility; and
- changes the shell primitive for creating realms to throw an error in case of
incompatible requested visibilities, rather than crashing.
Differential Revision: https://phabricator.services.mozilla.com/D14625
--HG--
extra : moz-landing-system : lando
Currently createStackMap makes a temporary clone of StackMapGenerator::mst_ on
every call. This will cause a heap allocation and free in the case where
mst_'s vector size exceeds its inline capacity (64 booleans). This patch
removes the cloning and instead adds a second MachineStackTracker,
augmentedMst_, to StackMapGenerator, which is used as the temporary inside
createStackMap. The expectation is that augmentedMst_'s vector will grow in
capacity monotonically during the lifetime of the StackMapGenerator, that is,
over multiple calls to createStackMap. This should significantly cut down on
heap (re)allocation caused by createStackMap.
--HG--
extra : rebase_source : 3a682e88571c1452f15efe711be3e403f64e0a8f
Because it release-asserts the compartment has a single realm.
I also renamed JS_GetCompartmentPrincipals to JS_DeprecatedGetCompartmentPrincipals
to discourage people from using it.
Differential Revision: https://phabricator.services.mozilla.com/D14252
--HG--
extra : moz-landing-system : lando
We were failing the realm assert in UnboxedLayout::makeNativeGroup in the browser.
It's possible the assert is overzealous and we don't need the AutoRealm, but this
makes it much easier to reason about the code.
Differential Revision: https://phabricator.services.mozilla.com/D14693
--HG--
extra : moz-landing-system : lando
This fixes bug 1406437. It also simplifies JSScript because it now always stores
a ScriptSourceObject directly instead of a CCW for one.
Differential Revision: https://phabricator.services.mozilla.com/D13974
--HG--
extra : moz-landing-system : lando
But keep the crashreporter disabled at runtime because it doesn't work
yet.
This has the side effect of creating the artifacts with the
crashreporter symbols and pdbs.
Differential Revision: https://phabricator.services.mozilla.com/D14550
--HG--
extra : moz-landing-system : lando
CCWs are not really associated with a single realm and we assert code doesn't
enter/request the realm or global of a CCW. However they currently still have an
ObjectGroup that's associated with a single realm. Using the same realm avoids
some potential memory usage issues.
Differential Revision: https://phabricator.services.mozilla.com/D14531
--HG--
extra : moz-landing-system : lando
In js.cpp, BindToAsyncStack used JSObject::isCallable to check the type of its
argument, and then BoundToAsyncStack (the native for the function returned)
assumed that it could call JSObject::as<JSFunction> on that value.
However, there are many things that are isCallable but not is<JSFunction>, two
examples being CCWs and function proxies.
Differential Revision: https://phabricator.services.mozilla.com/D14343
--HG--
extra : moz-landing-system : lando
We have a few places where C++ calls ChromeUtils::Import directly.
I fixed these to pass the target object directly instead of an empty Optional<>.
Differential Revision: https://phabricator.services.mozilla.com/D14180
--HG--
extra : moz-landing-system : lando
With same-compartment-realms enabled we can call a cross-realm Cu.importGlobalProperties
and we ended up defining properties on the wrong global.
Differential Revision: https://phabricator.services.mozilla.com/D14179
--HG--
extra : moz-landing-system : lando
For *incoming* wrappers this preserves behavior. We nuke *outgoing* wrappers
when all realms in the compartment have been nuked. To implement this I moved
the wasNuked flag from XPConnect to JS::Compartment as nukedOutgoingWrappers and
to JS::Realm as nukedIncomingWrappers.
The code to create a dead wrapper in the nuked compartment/realm case was also
moved into the JS engine. I added a shell test for it.
Differential Revision: https://phabricator.services.mozilla.com/D14149
--HG--
extra : moz-landing-system : lando
For *incoming* wrappers this preserves behavior. We nuke *outgoing* wrappers
when all realms in the compartment have been nuked. To implement this I moved
the wasNuked flag from XPConnect to JS::Compartment as nukedOutgoingWrappers and
to JS::Realm as nukedIncomingWrappers.
The code to create a dead wrapper in the nuked compartment/realm case was also
moved into the JS engine. I added a shell test for it.
Differential Revision: https://phabricator.services.mozilla.com/D14149
--HG--
extra : moz-landing-system : lando
This is an egregious hack. The web-platform-tests were not meant to run in the shell.
The eight tests that are included are the ones that we pass with flying colors.
In most of the others, we still have a failure or two.
Differential Revision: https://phabricator.services.mozilla.com/D11533
--HG--
rename : dom/imptests/testharness.js => js/src/jit-test/lib/w3c-testharness.js
extra : moz-landing-system : lando
This is an egregious hack. The web-platform-tests were not meant to run in the shell.
The eight tests that are included are the ones that we pass with flying colors.
In most of the others, we still have a failure or two.
Differential Revision: https://phabricator.services.mozilla.com/D11533
--HG--
rename : dom/imptests/testharness.js => js/src/jit-test/lib/w3c-testharness.js
extra : moz-landing-system : lando
If the JS::ResetTraceLogger() routine is called, then keep track of existing event payloads and keep their existence alive instead of clearing them. This data can still be referred to in another profiler session and can therefore cause to dangling pointers if we free them.
Differential Revision: https://phabricator.services.mozilla.com/D10277
--HG--
extra : moz-landing-system : lando
We add support for the wasm "anyref" type to the TypedObject system,
so that TypedObjects can represent wasm objects faithfully and we can
get proper boxing/unboxing when JS writes and reads these properties.
The new type is a reference type named "WasmAnyRef" / TYPE_WASM_ANYREF
internally, and it also appears as TypedObject.WasmAnyRef in JS.
Accesses to AnyRef fields are not optimized by the JIT at the moment,
but call into intrinsic functions in the wasm subsystem for sundry
predicates and boxing and unboxing. More can be done here.
Currently the code knows that an anyref in wasm is a possibly-null
JSObject* representing either an Object or a boxed value. More
complexity will appear when we box more values in the pointer. There
are "TODO/AnyRef-boxing" comments left in the code to mark places that
must definitely be adapted.
--HG--
extra : rebase_source : a08443ee58d2f4dd5fdc52f998e30c6a4d24be21
This is stage 0 of the anyref boxing/unboxing work.
At the JS->wasm boundary, when a JS value flows into an anyref, we box
everything that isn't already an Object or null into a WasmValueBox (a
distinguished NativeObject subclass with a null prototype). At the
wasm->JS boundary, when an anyref value flows out from wasm, we unbox
it back into the proper JS value. Note that strings and atoms and
other non-Object reference types are also boxed/unboxed this way.
This patch handles boxing and unboxing for function anyref parameters
and anyref returns (on the interpreter-only stubs path, since the JIT
stubs path is not used for reference types at this time), for wasm
globals-of-anyref, and for wasm tables-of-anyref. We don't have to
handle (ref T) parameters, returns, or globals, since they are not
exported to JS so as not to expose their types. And there are no
tables of (ref T) type.
The patch does *not* handle boxing/unboxing for values flowing into
and out of anyref struct fields for the prototype GC work. Doing so
will require work on our TypedObject implementation and can be
deferred to a later patch: the current system will simply fail to box
some JS values that flow into an anyref field or will incorrectly
convert those values to JS Object types; it may also reveal the
WasmValueBox object to JS in some cases when an anyref field is read.
This is annoying but safe.
The many "TODO/AnyRef-boxing" comments and accompanying asserts left
in the code mark places that we have to update when we implement an
optimized boxing, which will use a tagged format to avoid allocation
for small immediate values (integers, booleans, undefined) and
probably strings. Generally, the TypedObjects code that needs to
change to accomodate boxing/unboxing is not tagged in this way.
--HG--
extra : rebase_source : 66e2a3916a17a8eeba64c5ec30f632aa434c0401
Add a new class to extract tracelogger data using chunked buffers and use this to write the data out to the profiler JSON output. Copying the data in chunks lets us minimize our memory overhead when writing out to the profiler so a large array of millions of elements does not need to be allocated ahead of time.
Differential Revision: https://phabricator.services.mozilla.com/D11791
--HG--
extra : moz-landing-system : lando
We now emit JSOP_CALLEE or JSOP_ENVCALLEE (a new op) to load the callee.
JSOP_SUPERFUN and JSOP_SUPERBASE no longer have to walk the scope/environment
chain.
Differential Revision: https://phabricator.services.mozilla.com/D13688
--HG--
extra : moz-landing-system : lando
This was added in bug 833076 because back then TypeScript::SetThis assumed
non-null script->types. However since bug 875276 we don't need this anymore.
Differential Revision: https://phabricator.services.mozilla.com/D13652
--HG--
extra : moz-landing-system : lando
This is just a minor optimization, but it makes the bug fixed by part 2
reproducible when running jit-tests.
Differential Revision: https://phabricator.services.mozilla.com/D13650
--HG--
extra : moz-landing-system : lando
Ensure that "a instanceof b" has Xray semantics, i.e. that when b is a
XrayWrapper, that the wrapped object's getters, `Symbol.hasInstance`
hook and proxy traps are not triggered.
The toolkit/components/mozintl/test/test_mozintlhelper.js test was
updated to explicitly waive Xrays, instead of relying on the previous
behavior where Xrays were automatically waived.
Depends on D11591
Depends on D11591
Differential Revision: https://phabricator.services.mozilla.com/D11592
--HG--
extra : moz-landing-system : lando
There is currently no public API to call the 'instanceof' handler
without triggering proxies. The public method, JS_HasInstance, may
skip the default logic if a class has a non-null JSHasInstanceOp.
(i.e. js/src/proxy/Proxy.cpp and js/src/ctypes/CTypes.cpp ).
To serve the need of the next patch (which needs to trigger the
instanceof logic without triggering the proxy), this patch publishes the
js::InstanceofOperator method.
JS::InstanceOfOperator is the new name, and the new capitalization
matches the name of the abstract operation in the ES6 specification.
Differential Revision: https://phabricator.services.mozilla.com/D11591
--HG--
extra : moz-landing-system : lando
BaseStackFrame is split into two parts:
- BaseStackFrameAllocator is now responsible for dealing with stack
allocation and deallocation in all complex cases (which means
everything except for the simple native masm.Push and masm.Pop
cases).
- What's left of BaseStackFrame is then a simple-to-use API for the
rest of the compiler that maintains and checks invariants and does
various kinds of bookkeeping and hides the remaining differences
between the chunky and non-chunky stacks.
The latter class inherits from the former because this is simplest
(and it's easy to accomplish with 'protected').
There are a couple of minor functional changes here:
- The variable maxFramePushed_ now actually records the maximum value
of masm.framePushed, not the maximum stack height. The new behavior
is correct even with the chunky stack, since this value is used for
stack overflow checking. There should however be no observable
changes because of this. (Trivial reason: only ARM64 is affected
and we have no ARM64 products. Deeper reason: stacks are aligned at
coarser boundaries than our stack chunks, and have lots of headroom.)
- Member variables tracking the stack height are now set up in a new
method, onFixedStackAllocated(), which is called after
beginFunction() has allocated the space for the Header and Local
areas of the frame. The old behavior was correct but very obscure.
The new code is easier to understand.
--HG--
extra : rebase_source : b3a06eb2a845a76c671d3060fa9e77cb0e4e4b69
We rely on TypedObjects for the experimental wasm GC feature, but that
feature is Nightly-only and we should not be touching TypedObjects if
we don't need them. Furthermore we should just fail to compile
outright if wasm GC is enabled but TypedObjects are not.
--HG--
extra : rebase_source : e76a01ea25158aa6d3bd8760339e06be41dbba80
ICEntries and the fallback stub space are now stored in ICScript. The ICScript*
is stored in TypeScript to not increase sizeof(JSScript).
We need this for bug 1499324 but it also lets us greatly simplify the
BaselineDebugModeOSR code as this patch shows.
Note: some ICScript method definitions are still in BaselineJIT.cpp instead of
BaselineIC.cpp to make this patch easier to review. We could move them to
BaselineIC.cpp as a follow-up change.
Differential Revision: https://phabricator.services.mozilla.com/D11746
--HG--
extra : moz-landing-system : lando
This spewer design has two goals:
1. Provide a spew mechanism that has first-class support for slicing and
dicing output. This means that filtering by script and channel should be
the dominant output mechanism.
2. Provide a simple powerful mechanism for getting information out of the
compiler and into tools. I'm inspired by tools like CacheIR analyzer,
IR Hydra, and the upcoming tracelogger integration into perf.html.
Differential Revision: https://phabricator.services.mozilla.com/D11787
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
These macros tend to be handled quite poorly since the clang-format
tokenizer cannot figure out how to handle them.
Differential Revision: https://phabricator.services.mozilla.com/D13179
--HG--
extra : moz-landing-system : lando
