The end result we want is that on the web cross-compartment wrappers for
WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true
for both cases that are different-origin (as now) and cases that are
same-origin, since they might become different-origin due to document.domain
changes but we don't want that to affect the wrappers involved.
On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we
would have originSubsumesTarget == targetSubsumesOrigin in all web cases.
I claim that
originSubsumesTarget == targetSubsumesOrigin &&
(!targetSubsumesOrigin ||
(!originCompartmentPrivate->wantXrays &&
!targetCompartmentPrivate->wantXrays)) &&
"object is a WindowProxy or Location"
is a necessary and sufficient condition for using CrossOriginObjectWrapper.
Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin
are both false, then for the WindowProxy and Location cases we currently end up
with the following arguments to SelectWrapper:
securityWrapper: true
xrayType: XrayForDOMObject
waiveXrays: false
So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new
condition keeps doing.
If originSubsumesTarget and targetSubsumesOrigin are both true, then there are
two cases. If both compartments have wantXrays false (which is always the case
on the web), then we end up with the following arguments to SelectWrapper:
securityWrapper: false
xrayType: NotXray
waiveXrays: false
and SelectWrapper returns CrossCompartmentWrapper. We want to do
CrossOriginObjectWrapper instead, as explained above.
Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one
of the compartments has wantXrays set, then we get:
securityWrapper: false
xrayType: XrayForDOMObject
waiveXrays: might be true or false
and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM.
In this case we do _not_ want to start returning CrossOriginObjectWrapper, and
this is a non-web case anyway, since web compartments can't set wantXrays.
Differential Revision: https://phabricator.services.mozilla.com/D18030
--HG--
extra : moz-landing-system : lando
We want to indicate "we didn't actually manage to define your properties as
non-configurable" but we don't want to throw exceptions when people try to
Object.defineProperties with a non-configurable property in the list on a
WindowProxy.
Though maybe we should just silently ignore the "can't define non-configurable
on WindowProxy" bits in defineProperties and just return the object anyway?
The reason we do the "return null" bit in defineProperty is so that Caja and
the like can detect it, but if they're not using defineProperties to start with
they may not need to detect this "failure". On the other hand, Mark Miller
thinks the detection will be needed...
Differential Revision: https://phabricator.services.mozilla.com/D17516
--HG--
extra : moz-landing-system : lando
This adds a new configure option `--enable-wasm-codegen-debug`, which defaults
to true in debug builds (disable otherwise).
It's a first step so as to be able to use this in both the shell and browser,
using the env variables JIT_OPTION_{JitOption field name}.
Differential Revision: https://phabricator.services.mozilla.com/D18341
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
This is pretty straight-forward now and it's much nicer to encapsulate this in
TypeScript instead of having these types-related flags in JSScript.
Differential Revision: https://phabricator.services.mozilla.com/D18550
--HG--
extra : moz-landing-system : lando
As we add more fields to TypeScript (= JitScript in the future), the
AutoSweepTypeScript argument to JSScript::types() is becoming annoying.
This patch moves the argument to TypeScript::typeArray() and
TypeScript::inlinedCompilations() because that's the data affected by type
sweeping.
Differential Revision: https://phabricator.services.mozilla.com/D18549
--HG--
extra : moz-landing-system : lando
Baseline interpreter frames will have a TypeScript/ICScript we want to keep
around on GC.
The JSScript::typesDontCheckGeneration method will be removed in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D18548
--HG--
extra : moz-landing-system : lando
In js::SetPrototype we call GlobalObject::ensureConstructor. I think this is
only a problem for evalcx because other globals have an immutable prototype
chain.
Differential Revision: https://phabricator.services.mozilla.com/D18562
--HG--
extra : moz-landing-system : lando
The 64-bit wasm atomic ops have particularly stringent register
constraints on many platforms. These constraints were not expressed
well at the lowering stage, and in the case of cmpxchg and rmw on ARM
a constraint that the input value must be in registers distinct from
other values and the output was missing; gvn would therefore be
allowed to common values that should have been considered distinct.
--HG--
extra : rebase_source : 07dfb1cc82feeee5d83a1cc2269ee90825a792cb
extra : amend_source : 7462f1467fee417b7c37abe7f6b7b2060f2b4423
This adds a new configure option `--enable-wasm-codegen-debug`, which defaults
to true in debug builds (disable otherwise).
It's a first step so as to be able to use this in both the shell and browser,
using the env variables JIT_OPTION_{JitOption field name}.
Differential Revision: https://phabricator.services.mozilla.com/D18341
--HG--
extra : rebase_source : 37c717f4cc225a9a7d162df3b0312b68e39ad07e
Eventually this op could use an IC or some frontend/bytecode refactoring to make
it faster in the interpreter. For now following the C++ interpreter is the
simplest solution though.
Differential Revision: https://phabricator.services.mozilla.com/D17939
--HG--
extra : moz-landing-system : lando
The end result we want is that on the web cross-compartment wrappers for
WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true
for both cases that are different-origin (as now) and cases that are
same-origin, since they might become different-origin due to document.domain
changes but we don't want that to affect the wrappers involved.
On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we
would have originSubsumesTarget == targetSubsumesOrigin in all web cases.
I claim that
originSubsumesTarget == targetSubsumesOrigin &&
(!targetSubsumesOrigin ||
(!originCompartmentPrivate->wantXrays &&
!targetCompartmentPrivate->wantXrays)) &&
"object is a WindowProxy or Location"
is a necessary and sufficient condition for using CrossOriginObjectWrapper.
Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin
are both false, then for the WindowProxy and Location cases we currently end up
with the following arguments to SelectWrapper:
securityWrapper: true
xrayType: XrayForDOMObject
waiveXrays: false
So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new
condition keeps doing.
If originSubsumesTarget and targetSubsumesOrigin are both true, then there are
two cases. If both compartments have wantXrays false (which is always the case
on the web), then we end up with the following arguments to SelectWrapper:
securityWrapper: false
xrayType: NotXray
waiveXrays: false
and SelectWrapper returns CrossCompartmentWrapper. We want to do
CrossOriginObjectWrapper instead, as explained above.
Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one
of the compartments has wantXrays set, then we get:
securityWrapper: false
xrayType: XrayForDOMObject
waiveXrays: might be true or false
and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM.
In this case we do _not_ want to start returning CrossOriginObjectWrapper, and
this is a non-web case anyway, since web compartments can't set wantXrays.
Differential Revision: https://phabricator.services.mozilla.com/D18030
--HG--
extra : moz-landing-system : lando
The new rules for bounds checks for the bulk operations are that they
are per-element, this means we'll read and write individual elements
(bytes, table slots) until we hit an error or we've finished the task
according to the parameters.
Furthermore, reading and writing is from low addresses toward higher
as a general rule. However, for memory.copy, if the source and target
regions overlap and src < target then the direction is higher toward
lower.
In the absence of a memory.protect instruction (that could render
pages in the memory inaccessible) or a memory.shrink instruction
(ditto) this is pretty straightforward. This is so even in shared
memory that can be growing concurrently with the bulk operation, since
there are no fences and the write order therefore is not actually
observable absent a trap. We obtain the memory size, compute the
in-bounds portion of the source and target, and perform the operation
using a standard libc-level bulk operation. If there were
out-of-bounds portions of the source or target we then throw an
exception. Note that in the case of high-to-low order for memory copy
this may mean nothing is written (because we're OOB at the high end of
the regions, where we start reading and writing).
One final wrinkle is that we can't error out for arithmetic overflow
when we compute the bounds: we must work as-if we're checking the
source bound, reading the source byte, checking the target bound,
writing the target byte, and so on. So we go from using CheckedInt
for arithmetic to using 64-bit integers.
Additionally, we need to be mindful to use safe-for-races operations
when we might be operating on shared memory.
--HG--
extra : rebase_source : 638b5cb2dd539d18f5340019ca9a94ac21155355
Once we have the reftypes proposal (which we already have, but behind
another ifdef) we'll need to go to varuint32 for the table index but
not for the memory index, hence a wee bit of complexity here, hidden
behind a function.
--HG--
extra : rebase_source : 9d51b410cb4a32855c8362f70219b53111ed3a2f
In the optimized stub, we forgot to account for the frameAlignExtra
word when computing the offset from the SP at which stack args are
read. The test case finds the problem on the ARM64 simulator, and
does not need any special parameters, just to run long enough for a JS
JIT to kick in.
Also a drive-by fix for an incorrect NaN canonicalization along the
non-toValue path, cf the Double case right above it. This code
changed recently when I introduced the ScratchFloat32Scope, but the
bug predates that.
Differential Revision: https://phabricator.services.mozilla.com/D18942
--HG--
extra : rebase_source : 703a516fd6b7ac0e5a3dbb0a9ee2703d04188a9b
extra : amend_source : b9b86223bd2f7153c55c45854a12056b1217210f
Passive segments carry a type code (currently always AnyFunc but in
the future also AnyRef and other ref types) and each element is not a
raw function reference, but an initializer expression that must be a
RefFunc opcode with a function index, followed by End.
This use of RefFunc creates a circularity in the proposal space, since
reftypes has not definitively assigned an opcode to that operation.
Also, we want to ship bulk copy without having to ship reftypes or
handle RefFunc generally. So RefFunc is defined provisionally here
outside the opcode space and is only recognized in this one context;
that will change once we have function support in our reftypes
implementation.
--HG--
extra : rebase_source : b63b343c37e697e92dcbee21c4137aace8492e93
extra : histedit_source : b1d0879255b7116f27a26151398d31e5283a78c3%2Cf8067891a3483a0f2c5e429c83888bead4091b3a
Existing code crashes on IonIC frames. Instead, use FrameIter to
determine caller. This also simplifies WASM handling. Also make inJit
use a similar approach for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D18151
--HG--
extra : moz-landing-system : lando
This is a replacement for pn_op that is used in BytecodeEmitter.
This patch just adds the field, but keeps using pn_op.
Part 4 removes the usage of pn_op for FunctionNode.
Differential Revision: https://phabricator.services.mozilla.com/D18328
--HG--
extra : moz-landing-system : lando
CodeNode was shared between ParseNodeKind::Function and ParseNodeKind::Module,
but Module only uses `pn_u.code.body`.
Separated them for further refactoring for function part.
Differential Revision: https://phabricator.services.mozilla.com/D18327
--HG--
extra : moz-landing-system : lando
pn_op for CodeNode can only be JSOP_NOP, JSOP_LAMBDA, and JSOP_LAMBDA_ARROW.
Removed other cases.
Also removed the override with JSOP_FUNWITHPROTO given the field is never read
after the function.
Differential Revision: https://phabricator.services.mozilla.com/D18325
--HG--
extra : moz-landing-system : lando
That will make it detected when we bump the MACOSX_DEPLOYMENT_TARGET
to a value >= 10.12.
Differential Revision: https://phabricator.services.mozilla.com/D18310
--HG--
extra : moz-landing-system : lando
Linearly searching the shape lineage can be expensive. It is going to cause branch misses and cache misses since we are traversing a linked list. Since this is done frequently enough, it may be worth while to "cache" results from the linear search. This revision hopes to lazily allocate a small linear cache after the first linear search on a shape. The results from each linear search afterwards will be placed into the cache. If the jsid that is being searched for is frequently looked up then we obtain a "cache hit" from a quick search in the cache. Otherwise, we fall back to a linear search and append the new entry to the cache. Once the cache is full, it will transform into a shape hash table like the previous approach.
Differential Revision: https://phabricator.services.mozilla.com/D12155
--HG--
extra : moz-landing-system : lando
This is just a VM call in the interpreter. We could optimize this with an IC or
inline path if it ever becomes a problem.
Differential Revision: https://phabricator.services.mozilla.com/D17935
--HG--
extra : moz-landing-system : lando
This adds js::SingletonObjectLiteralOperation and calls it from both the
interpreter and Baseline. The Baseline compiler still has a fast path for the
cloning-not-necessary case.
Differential Revision: https://phabricator.services.mozilla.com/D17934
--HG--
extra : moz-landing-system : lando
The end result we want is that on the web cross-compartment wrappers for
WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true
for both cases that are different-origin (as now) and cases that are
same-origin, since they might become different-origin due to document.domain
changes but we don't want that to affect the wrappers involved.
On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we
would have originSubsumesTarget == targetSubsumesOrigin in all web cases.
I claim that
originSubsumesTarget == targetSubsumesOrigin &&
(!targetSubsumesOrigin ||
(!originCompartmentPrivate->wantXrays &&
!targetCompartmentPrivate->wantXrays)) &&
"object is a WindowProxy or Location"
is a necessary and sufficient condition for using CrossOriginObjectWrapper.
Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin
are both false, then for the WindowProxy and Location cases we currently end up
with the following arguments to SelectWrapper:
securityWrapper: true
xrayType: XrayForDOMObject
waiveXrays: false
So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new
condition keeps doing.
If originSubsumesTarget and targetSubsumesOrigin are both true, then there are
two cases. If both compartments have wantXrays false (which is always the case
on the web), then we end up with the following arguments to SelectWrapper:
securityWrapper: false
xrayType: NotXray
waiveXrays: false
and SelectWrapper returns CrossCompartmentWrapper. We want to do
CrossOriginObjectWrapper instead, as explained above.
Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one
of the compartments has wantXrays set, then we get:
securityWrapper: false
xrayType: XrayForDOMObject
waiveXrays: might be true or false
and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM.
In this case we do _not_ want to start returning CrossOriginObjectWrapper, and
this is a non-web case anyway, since web compartments can't set wantXrays.
Differential Revision: https://phabricator.services.mozilla.com/D18030
--HG--
extra : moz-landing-system : lando
Creating too many SSOs can apparently slow down the debugger and it's just
wasteful.
This patch passes the SSO down to the cloning functions. One nice side-effect is
that the self-hosting SSO code now lives in SelfHosting.cpp instead of JSScript.cpp
Differential Revision: https://phabricator.services.mozilla.com/D18347
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
This will allow us to correctly handle CheckedUnwrapDynamic on wrappers around
WindowProxy and Location.
Differential Revision: https://phabricator.services.mozilla.com/D17882
--HG--
extra : moz-landing-system : lando
We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
Existing code didn't handle IonIC frames, but the
FrameScriptIter::script function does the right thing for us here.
Differential Revision: https://phabricator.services.mozilla.com/D18151
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
This will allow us to correctly handle CheckedUnwrapDynamic on wrappers around
WindowProxy and Location.
Differential Revision: https://phabricator.services.mozilla.com/D17882
--HG--
extra : moz-landing-system : lando
We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
Eventually this op could use an IC or some frontend/bytecode refactoring to make
it faster in the interpreter. For now following the C++ interpreter is the
simplest solution though.
Differential Revision: https://phabricator.services.mozilla.com/D17939
--HG--
extra : moz-landing-system : lando
This is just a VM call in the interpreter. We could optimize this with an IC or
inline path if it ever becomes a problem.
Depends on D17934
Differential Revision: https://phabricator.services.mozilla.com/D17935
--HG--
extra : moz-landing-system : lando
This adds js::SingletonObjectLiteralOperation and calls it from both the
interpreter and Baseline. The Baseline compiler still has a fast path for the
cloning-not-necessary case.
Depends on D17645
Differential Revision: https://phabricator.services.mozilla.com/D17934
--HG--
extra : moz-landing-system : lando
Remove all(*) uses of ScratchDoubleReg / ScratchFloat32Reg in common
code and tier-1 macro-assemblers, and use ScratchDoubleScope /
ScratchFloat32Scope exclusively. This sometimes leads to a very minor
amount of extra code, but ensures that we do not reuse a live
register.
(*) There are a couple of uses left, but these only check that the
scratch regs aren't used where they can't be used or check whether the
scratch regs need to be saved and restored across a call to external
code.
--HG--
extra : rebase_source : 9113a93e4d9a63c17257329302f9d648b7cf7298
extra : amend_source : b6b234553602713032ca034e6d11fa1942a3ca17
`OffThreadPromiseRuntimeState::internalDrain` assumes that if
`internalDispatchQueue_` is empty but `live_` is not, then there must be
`OffThreadPromiseTasks` still in flight that it should block for. To support
reentrant calls to `internalDrain`, we need to make two changes:
- First, `internalDrain` needs to dequeue jobs one at a time, rather than
swapping out the entire queue, which makes the queue look empty when there are
still jobs yet to be run.
- Second, `OffThreadPromiseTask::run` needs to remove each task from `live_`
*before* calling its `resolve` method, so that if the last task in the queue
reenters `internalDrain`, that won't mistake the final entry in `live_` for
something it must block on.
Since there are still `OffThreadPromiseTasks` that get registered in `live_`
but then get destructed without being run (for example, in `WasmJS.cpp`'s
`ResolveResponse_OnFulfilled`), we cannot assume that the `run` method will
unregister all tasks; the destructor still needs to check if unregistration is
necessary. So we factor out unregistration into its own method.
Differential Revision: https://phabricator.services.mozilla.com/D17704
--HG--
extra : moz-landing-system : lando
To support reentrant calls to OffThreadPromiseRuntimeState::internalDrain, we
need to be able to tell reliably whether the queue is empty or not. The present
implementation tactic of using a Vector to represent the queue, pushing new jobs
onto the end, and then stealing the entire vector and processing all the jobs in
one pass over its make it appear that the queue is empty when, in fact, there
remain jobs that have not yet been run.
Since we have a true FIFO type ready at hand, we can use that to give the
off-thread promise machinery a more traditional implementation that dequeues one
job at a time.
Differential Revision: https://phabricator.services.mozilla.com/D17702
--HG--
extra : moz-landing-system : lando
It relies on AC_TRY_RUN, which doesn't work on cross-compiles. What this
means is that the feature has been disabled on mac builds on automation
ever since we switched to cross-compiles. It's still enabled on local
mac builds because the test runs there, and returns "yes". It also means
it's disabled on Android, where it probably works (at least debug tests
on try don't complain).
It also doesn't currently run on Windows because it's in a skipped
section on Windows, but if moved out of that section, the test returns
"no".
So, we remove any configure test for the feature, in favor of
preprocessor checks in nsTraceRefcnt.cpp.
Depends on D18055
Differential Revision: https://phabricator.services.mozilla.com/D18056
--HG--
extra : moz-landing-system : lando
Autoconf 2.13 documentation says: "If the memcmp function is not
available, or does not work on 8-bit data (like the one on SunOS 4.1.3),
add `memcmp.o' to output variable LIBOBJS."
The documentation of more recent versions of autoconf also mention NeXT
x86 OpenStep, and say "This macro is obsolescent, as current systems
have a working memcmp. New programs need not use this macro."
We're also not using LIBOBJS, so, even if somehow some machine had the
test detect something weird going on, the result of the test wouldn't
have an effect on the build anyways.
Apart from that, it's also one of the few tests that relies on actually
running a compiled binary during configure, which requires some
autoconf-specific definition of cross-compilation (where --target=i686
--host=x86_64 is not cross-compilation), and we're better off getting
rid of such tests completely.
Depends on D18054
Differential Revision: https://phabricator.services.mozilla.com/D18055
--HG--
extra : moz-landing-system : lando
While not related, it turns out this test was opted in by ourselves,
while it's practically useless. Recent autoconf documentation says it's
obsolescent, and even autoconf 2.13 documentation said with "recent
versions of the GNU C compiler", the issue it's detecting "is becoming
a less prevalent problem". Recent as of 20 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D18054
--HG--
extra : moz-landing-system : lando
This gcc 4.8.2 workaround (from bug 1219050) is no longer needed because Firefox currently requires gcc 6.1 or later (as of bug 1444274).
Differential Revision: https://phabricator.services.mozilla.com/D5506
--HG--
extra : moz-landing-system : lando
Now that we decide whether the collection will be incremental or
non-incremental before taking the session lock, we can tighten these
assertions.
Differential Revision: https://phabricator.services.mozilla.com/D18021
--HG--
extra : moz-landing-system : lando
I am bit surprised myself, but just removing the getPropertyDescriptor trap seems to mostly work.
The only real special case here is the XPC Sandbox, which I changed to keep using its getPropertyDescriptorImpl.
testSetPropertyIgnoringNamedGetter.cpp didn't even really need its getPropertyDescriptor implementation.
Differential Revision: https://phabricator.services.mozilla.com/D17386
--HG--
extra : moz-landing-system : lando
The interpreter will use this to set the frame's ICEntry* pointer at jump target
ops and then it will just bump this pointer after each JOF_IC op. This way the
interpreter can use Baseline ICs with minimal overhead compared to the Baseline
JIT.
Differential Revision: https://phabricator.services.mozilla.com/D17115
--HG--
extra : moz-landing-system : lando
The bytecode emitter used to call checkTypeSet for each JOF_TYPESET op. Despite
correctness asserts in the TypeScript code, this was pretty error prone. Doing
something similar for JOF_IC ops would have made it worse.
The solution is to move this check to BytecodeEmitter::emitCheck (called for
each opcode we emit), so we don't have to worry about this anymore.
Differential Revision: https://phabricator.services.mozilla.com/D17114
--HG--
extra : moz-landing-system : lando
This will change a bit in the future but I think this is a reasonable
initial version.
Differential Revision: https://phabricator.services.mozilla.com/D16801
--HG--
extra : moz-landing-system : lando
This is needed to test the test harness's handling of a negative leak
being reported by the XPCOM leak checker.
Depends on D17535
Differential Revision: https://phabricator.services.mozilla.com/D17536
--HG--
extra : moz-landing-system : lando
In order to test the test harness's handling of a process failing to
produce a leak log, add a special function that disables the bloat log
output.
Differential Revision: https://phabricator.services.mozilla.com/D17534
--HG--
extra : moz-landing-system : lando
Also allow the nursery to shrink up to half it's current size, previously
it'd be one chunk at a time. Growing is still capped at twice the current
size. These limits tend to prevent it changing too dramantically for small
changes in allocation patterns.
Differential Revision: https://phabricator.services.mozilla.com/D17594
--HG--
extra : moz-landing-system : lando
We now require the presence of a DataCount section to forward-declare
the number of data segments if the code uses memory.init or data.drop.
Those instructions may only reference segments in the range
[0..dataCount-1].
If there is a DataCount section then the number of forward-declared
segments must match the actual count of segments.
We no longer need the deferred validation state, so we can remove it.
That's pretty mechanical and comprises the bulk of the patch.
text->binary translation will insert a DataCount section if
memory.init or data.drop is used and the DataCount section is not
present in the text (this will be the common case); however, if the
section is present in the text then translation will just encode
whatever the text contains. The section is not synthesized if it is
not needed.
Also: test cases for all of this.
Also: drive-by fix the passive-segments test cases: do not duplicate
functionality from wasm-binary.js, and use opcode names when possible.
--HG--
extra : rebase_source : 1f24050fce4b70124d124c705230a4c818dc74df
extra : histedit_source : 55cf265210ecdd8ea234e66949866e9d5beafb11%2C59e3ef279dd0f63f0bfb448951d61ebe5707d74c
Boris Zbarsky
Gurzau Raul
Brindusan Cristian
Benjamin Bouvier
Alex Gaynor
Mike Hommey
Jan de Mooij
Kris Maglione
André Bargull
Lars T Hansen
Oana Pop Rus
Tooru Fujisawa
Noemi Erli
Robin Templeton
Jim Blandy
Adrian Wielgosik
Cosmin Sabou
Bogdan Tara
Ted Campbell
Andy Wingo
Coroiu Cristina
Sylvestre Ledru
Jon Coppeard
Denis Palmeiro
Ciure Andrei
Bob Clary
Daniel Varga
Emanuel Hoogeveen
Csoregi Natalia
shindli
Razvan Maries
Ms2ger
Steve Fink
Nicolas B. Pierron
Andrea Marchesini
Chris Peterson
Myk Melez
Paul Bone
Sebastian Hengst
Dorel Luca
Tom Schuster
Sean Stangl
Randell Jesup
Jeff Walden
Andrew McCreight