As the SP is weird on ARM64 a number of adjustments must be made to
the stubs code. On the one hand we never have to check for stack
alignment; on the other hand we don't get to use raw Push and Pop to
manipulate the stack, the word-aligned stack in the JIT ABI requires
some unusual adjustments, and the fact that the JIT treats x28 (the
PseudoStackPointer) as non-volatile requires it to be saved and
restored, or recomputed.
On ARM64 we do not have a pop-return-address-from-memory-and-return,
and this causes a slight problem for the interrupt stub code. On MIPS
this is fixed by using HeapPtr as a temp for the return address and
then restoring HeapPtr in the branch delay slot, but ARM64 does not
have branch delay slots either.
For now I'm using x28 to hold the return address since Wasm code does
not use x28 (it is not allocatable even in wasm code at this point)
and the interrupt stub only runs when the machine is in the wasm
state. If this turns out not to be workable we probably need to
reserve another register just for this.
--HG--
extra : rebase_source : bc6f809305fdb8713cd93170ec434ae1d8e64243
Since the SP behaves unusually on ARM64 we get architecture-specific
code paths for the prologue, the epilogue, and the unwinding, and the
Frame must also be 16-byte aligned.
--HG--
extra : rebase_source : d6bca83621abd882d7cdf3be6a594d96ac2ec4d9
extra : source : fe253cc42e453dec1199b4284c84425ed6cacb1a
The only remarkable thing about this patch is that it sets up the
assembler to use the native SP, not the pseudo-SP used by the JS
baseline compiler. The stubs and frame code (bug 1441142) also
assumes this. Doing this, we generate fewer instructions and we gain
a register (though we do not yet use that register here because it is
used for interrupt handling, see the other bug).
--HG--
extra : rebase_source : 2f4a9dec5853470c7cf315b26b28893f420db29d
extra : intermediate-source : ac5df2f178cbf8b560efe9551ff9dc46e8e030e5
extra : source : 34bd5eae004e6aad8dafd288e4c4c1935d69976e
ARM64 cannot allocate stack in word-sized increments (well it can, but
SP cannot be used to dereference it unless double-word aligned). So
modify the stack abstraction to allocate the stack in larger, aligned
increments.
Here we allocate in 8-word increments, and we preallocate the first
8-word chunk when we enter the function, both since "empty stack" is
expected to be a common occurrence and because a short stack is
expected to be typical. If we're lucky, few stack
allocations/deallocations will actually be necessary. Future work
will try to get a grip on the best chunk size.
--HG--
extra : rebase_source : 9270d5257a4048dd789dab251aacf6727995d371
extra : intermediate-source : 6289887b1735ee87ec08db8df5bec686b91a48a0
extra : source : c6c50d230e354f9b6a2c5e7bdc2aad4a6e7da0ae
Make wasm::HasCompilerSupport() and wasm::BaselineCanCompile()
know that ARM64 compilation is supported.
--HG--
extra : rebase_source : b976cec924d270ff46bcfbb5a7f5e6bfc78ad546
extra : intermediate-source : d7c0cdc04e7858b764314708eb48ed7d40677baf
extra : source : 061bb6ba20742e0d9913a8fbfec6874e3110dfee
This patch doesn't change the functionality, it just splits out the code into
separate functions that are easier to read.
MozReview-Commit-ID: Gx05YCxGgve
--HG--
extra : rebase_source : 3b7250cea630bebf35992bb69e651509c863c1c6
mCleanedUp is a VarCache variable, which mirrors the canonical value of the
network.predictor.cleaned-up pref. When the canonical pref value is modified,
e.g. by SetBool(), then mCleanedUp is also updated.
But the updating relationship is one-way -- if mCleanedUp is modified, the
canonical value of the pref is not updated. Such an inconsistency is bad! For
example, Predictor.cpp will use mCleanedUp's value, but about:config will show
the canonical value.
(For this reason, VarCache prefs are meant to be read-only outside of libpref.
Bug 1436655 will enforce this.)
This patch changes mCleanedUp so it's not a VarCache variable, avoiding the
mirroring issue.
MozReview-Commit-ID: LIG02gMkRjF
--HG--
extra : rebase_source : 273b2372ce718b0f346695a0dc96a189cd3ba233
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
This way we don't include it in all the binding headers. We only need
jsfriendapi.h for the static_asserts involving JSJitInfo, so we move those to
PrototypeList.cpp.
MozReview-Commit-ID: 7KOmbjwSBOD
When we run tests in parallel (and probably occasionally when we don't), we
sometimes wind up getting a DOMContentLoaded event for about:blank before we
actually start loading the background page, which causes tests which rely on
the background page being loaded to fail.
This also fixes some noisy warnings from XPIProvider which make actual issues
more difficult to diagnose.
MozReview-Commit-ID: 4CiccISJ7Pt
--HG--
extra : rebase_source : 25356f5162b19cd28a6f8d004e04a85038ecff28
