I would like to migrate the update directory to use a version of the hash consistent with what our installer generates as part of the work already being done to migrate the update directory (Bug 1458314).
This patch is a bit of a shim to ensure that no one uses the newly-exposed nsXREDirProvider::GetInstallHash to get the *old* value before Bug 1458314 lands. This way new callers will get a value that is stable, but also consistent with the hash generated by the installer.
Differential Revision: https://phabricator.services.mozilla.com/D5334
--HG--
extra : moz-landing-system : lando
When the window temporarily loses focus (e.g. due to auto-fill popups),
don't call setFocus(false). Otherwise, we can end up disrupting user
interaction (e.g. causing the auto-fill popup to flicker). Only call
setFocus(false) when we are reasonably sure the focus loss is not
temporary.
Differential Revision: https://phabricator.services.mozilla.com/D5329
To avoid unnecessary setActive calls, only call it when we have a
display and when the display acquires or releases a surface. In other
cases, we can delay the setActive call until later.
Differential Revision: https://phabricator.services.mozilla.com/D5328
Test cases for new instructions {mem,table}.{init,drop} and table.copy.
* New file passive-segs-nonboundary.js:
This tests the new instructions for "normal" (non-boundary) cases enough to
be reasonably convinced that the implementation works. It does not test any
exceptional/boundary cases, except for the case where we attempt to call
through an empty table slot.
This file also incorporates tests for memory.copy and memory.fill that were
previously in memory-bulk.js, which, in turn, has been removed.
* New file passive-segs-boundary.js:
This tests boundary / validation cases for the new instructions. Almost all
tests wind up throwing some kind of exception.
--HG--
extra : rebase_source : ec91c595c2f9af92ac440134cf965c736b90d03a
This patch adds support for: {memory,table}.{init,drop} and table.copy, in
the areas of code generation and implementation. Code generation is trivial
and done simply by creating calls to the following new functions:
Instance::memInit Instance::memDrop
Instance::tableInit Instance::tableDrop Instance::tableCopy
For both Ion and Baseline, the actual code generation for memory- vs table-
cases is so similar that a single function is used for both cases, and given
only a bool to differentiate them (eg EmitMemOrTableDrop, etc).
The new Instance::{mem,table}::Init functions then pull out the relevant
segment data (via instance->code()) and initialisation data (directly
attached to the instance) [per patches 4 and 5 respectively] and perform the
required updates.
All of this is mechanical and in line with existing code.
--HG--
extra : rebase_source : 4cf3cc503fe7fe24b4995fe51383851e84bf99fa
This patch adds a general mechanism that allows the Wasm compilers and
verifier to handle situations where the correctness of some constructions seen
in the byte stream cannot be determined until further along in the byte stream
-- in effect, forward references. It then uses this mechanism to check data
segment indices that appear in the instruction section (resulting from
memory.{drop,init} instructions) as the number of data sections will not be
known until after the code section.
* new struct DeferredValidationState, which holds whatever state is required
* new type ExclusiveDeferredValidationState, needed because
DeferredValidationState is shared between compilation threads and is mutable
* the new DeferredValidationState lives in class ModuleGenerator, since that
is really the running state for the compilation of a given module.
* a reference to the DeferredValidationState is added to OpIter, so that the
iterator can update the state as it visits instructions.
* consequently, there is a bunch of plumbing (extra parameters) to get a
reference to the DeferredValidationState to places where an OpIter has to be
created.
* also, CompileTask acquires a reference to the DeferredValidationState, as
there is no other way to get hold of it in
wasm::ExecuteCompileTaskFromHelperThread.
* when iteration is finished, we call
DeferredValidation::performDeferredValidation so as to perform any final
checks. This takes a const ModuleEnvironment& parameter, so that it can
crosscheck the deferred state against information collected in the
environment.
* compilation runs use the DeferredValidationState in the ModuleGenerator. But
pure validation runs (wasm::Validate) have no associated ModuleGenerator.
So it simply creates its own DeferredValidationState on the stack and uses
that.
Although at first it seems plausible to add this mutable shared state to
CompileTaskState, that is not so attractive because it means
* plumbing that into the core of the compilers. It contains information about
task management that has nothing to do with the details of compilation.
* there's no way to pull out the deferred validation state into its own type
without using a different lock than for CompileTaskState. In other words,
there appears to be no way to go from an ExclusiveData<CompileTaskState> to
an ExclusiveData<some field of CompileTaskState>.
In terms of the actual deferred checking added:
* data segment indices seen in memory.{drop,init} instructions are noted in
the running state. At least, the highest value is noted, along with its
bytecode offset. That way, if any index exceeds the number of data sections
(discovered later), we can reject the module and issue a suitable error
message. The message will be for the highest offending value rather than
the first appearance of an offending value, but that is presumably good
enough.
--HG--
extra : rebase_source : dd60f21edc124361109e7b8d1ebe5faec4e9b058
This patch adds support for: {memory,table}.{init,drop} and table.copy, in
the areas of parsing, AST representation, binary reading/iteration and
validation (pipeline stages up to but not including code generation). This
is mechanical and in line with existing code.
--HG--
extra : rebase_source : de483c851dce723bb6618d24ac35ba1c05de0721
This changes classes ElemSegment and DataSegment so that passive segments
can be represented. The basic change is to change the type of the |offset|
field from InitExpr to Maybe<InitExpr>, with Nothing denoting a passive
segment, and rename it to |offsetIfActive|.
The relevant AST types are changed similarly, along with the parsing and
validation code.
There's a new enum class InitializerKind to encapsulate the binary encoding
changes, per the bulk-memory/lazy-initialiser proposal.
Module::initSegments, when processing segments, is changed so as to skip
passive segments (since those must be deferred till run time). It also uses
the new helper ComputeWasmCallee from the previous patch in the series, to
compute initialisation values for active element segments.
This patch also adds code to create the {Elem,Data}SegmentInitVectors for
passive data and element segments at instantiation time. This is done in
Instance::init. For memory.init, that means copying initialising bytes from
the bytecode image. For table.init, a new helper function ComputeWasmCallee
computes the (entry point, instance pointer) pairs.
ComputeWasmCallee is not new code. It merely encapsulates existing logic that
would otherwise have to be duplicated for active and passive table
initialisers. It is called from Instance::initSegments, where it processes
active element segments, and Instance::init, where it processes passive
element segments.
--HG--
extra : rebase_source : 4c2c271a412d2a1051987ba0eee72bf66b0d7123
At run time, the implementation of {memory,table}.init needs to know the
actual bytes to be copied to complete the required initialisations, for
passive initialisers. It seems simplest to compute them exactly at
instantiation time, and have the computed data owned by the instance.
This also means it is possible for that data to be released by
{memory,table}.drop, independently of all other instances.
This patch adds new types DataSegmentInit, ElemSegmentInit,
DataSegmentInitVector, and ElemSegmentInitVector to hold this data. They are
explained in detail in a comment in WasmTypes.h.
For a data segment, the initialising values for a memory are merely bytes, but
for a table it is more complex -- a pair of (entry point, instance pointer).
This patch also adds a type WasmCallee to encapsulate that.
--HG--
extra : rebase_source : adaee69ee3662432bd2fc6e9924b8ce8093a7a46
This patch moves |const DataSegmentVector dataSegments_| and |const
ElemSegmentVector elemSegments_| from class Module to class Code, so as to
make their lifetimes at least as long as that of any instance derived from the
originating module. That is because they need to be reachable from an
Instance, in turn because they need to be consulted at runtime by the
implementation of {memory,table}.{init,drop}.
The change is mostly mechanical. Functions that had to change include:
* "sizeOf" memory reporting functions
* serialisation/deserialisation functions
The only complication is in Module::instantiate. In the case where
debugging is active, the resulting instantiation cannot share code with
other instantiations of the same module, and many structures are cloned.
This patch accordingly adds cloning of the data segments (easy) and the
element segments (not so easy) since ElemSegment has no copy constructor.
--HG--
extra : rebase_source : 3e3c74eefc04a742eed1606161ac2c7088870b3e
Some small changes to class Table:
* Table::set no longer takes an |Instance&| but rather a |const Instance*|.
This because we now need to call Table::set at run time, from
Instance::tableInit, at which point we only have an Instance* available, not
an Instance&.
* There's a new method Table::copy, which copies elements. Used to
implement Instance::tableCopy.
--HG--
extra : rebase_source : 0e3ad6c6a2605b34d16742da4cb9177f0eeba1e0
No functional change. Contains layout, naming and removal-of-duplicate-
expression changes to Instance::{memCopy,Fill} so as to be consistent with new
Instance:: functions added in patch 8 of this series.
The duplicated expression |CheckedU32(len - 1)| is lifted out into its own definition.
--HG--
extra : rebase_source : 5fcaccc472f7f9645221687441ebffef12e9acee
