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
Rather than searching from the beginning (old end) of the cache,
LiveSameFrameCache::find can search from the young end of the cache, popping
invalid stack entries as it goes.
This means that the number of entries searched is related to the number of
cached frames popped since the last stack capture, not the total number of
entries in the cache.
This also removes the need for iterators, iterator arithmetic, or any random
access to the stack; the function simply uses the vector's 'back', 'popBack',
'empty', and 'clear' methods.
MozReview-Commit-ID: DCFt0uhiqql
--HG--
extra : rebase_source : 1116f7df31387bb7e9f0419738867ea64f28c1c6
extra : histedit_source : 44da1f91484b02d4ceeac33b3a7f8075198579df
When capturing frames in an activation that had both 1) an async parent stack
established by AutoSetAsyncStackForNewCalls and 2) SavedFrames cached in the
activation's LiveSavedFramesCache, SavedStacks::insertFrames would supplant the
SavedFrame chain from the cache with the async parent stack, causing frames to
be dropped.
The code also looked for frames in the wrong activation's LiveSavedFramesCache.
The code assumed that only the parent of a frame whose hasCachedSavedFrame flag
is set could be retrieved from the cache; this was pessimistic, as we can
compare the cached and actual pc's, and potentially provide cache hits for the
youngest frame with a flag set.
MozReview-Commit-ID: 8tXTI43pjYr
--HG--
extra : rebase_source : 33048a95e8519a323933bb10e4d366c49082b8a5
extra : intermediate-source : a4c506d989bd6aa0054e37ec4d6fed9b3af216bf
extra : source : 1bda10ce352b374aa1cd3913715d2d31cb42614d
extra : histedit_source : a5014695d2271c4ff96e32897b9e51eb908be925
I botched another patch in this series because I was confused about when zero
meant "no limit" and when it actually just meant zero, so I figured I'd fix this.
MozReview-Commit-ID: 5vgzKGSKL8F
--HG--
extra : rebase_source : dc57c22b08455a1867eeaa139b3045d2ae181cef
extra : histedit_source : e82898f74e8568bbbd10f7589427f5fbbcfe24fa
Many operations on strings are also moved from builtin/String.cpp to vm/StringType.cpp.
--HG--
extra : rebase_source : 9239b1f1691962b5f1358d65eaae278780ae3f84
extra : source : cfd781da349e59c8d6b9fea7efed04a0b2124a61
A jit::BaselineFrame is followed in memory by a jit::JitFrameLayout; as the
stack grows downwards, the JitFrameLayout is pushed first, "followed" by the
BaselineFrame at lower addresses, and finally by locals and the operand stack.
A BaselineFrame* points, naturally, at the BaselineFrame structure, but we use
the address of the JitFrameLayout as the address for a physical Ion frame -
actually, a pointer to its base class, jit::CommonFrameLayout. This means that,
if OSR replaces a BaselineFrame with an Ion frame, then walking the stack with a
FrameIter will see an Ion frame where a BaselineFrame used to appear, and the
LiveSavedFrameCache::FramePtr we'll construct from that FrameIter will be
different.
If the LiveSavedFrameCache wants to assert that frames with their bits set
indeed appear in the cache, then we'd better clear the flag whenever we OSR the
frame. But this is a pity; it's still the same frame, representing the same
function activation.
Meanwhile, both BaselineFrame and CommonFrameLayout have their own
hasCachedSavedFrame flags, which is confusing.
This patch changes FramePtr to use a jit::CommonFrameLayout* for both Baseline
frames and physical Ion frames, so OSR does not change the frame's address, and
use CommonFrameLayout's hasCachedSavedFrame flag for both types, so that OSR
need not take any explicit steps to propagate the cached flag to the new frame.
MozReview-Commit-ID: rOMjUXlwIQ
--HG--
extra : rebase_source : 360cca36216e24b5668c28e7f4d02ef76b6a0fb8
extra : source : 000d13ca4b5c8427308753a4a1e23f56245dc19f
Some variants of AbstractFramePtr have a cached saved frame flag, and others
don't, but the whole point of LiveSavedFrameCache::FramePtr is that it
represents a frame that does have a flag.
Rather than one variant of FramePtr that is an AbstractFramePtr (restricted to
certain variants), flatten out the two enums into one, and make FramePtr the
sole authority on which sorts of frames we have, and how to access their flags.
This means there is no need for hasCachedSavedFrame accessors on
AbstractFramePtr, just on the individual concrete frame types.
MozReview-Commit-ID: BRVdfqOqBsG
--HG--
extra : rebase_source : 479940f862b861a5dc05be5e2b02a357f3a58c1b
extra : source : 22eb481891541995573ff8a223393567ccfecda6
This obviates dynamic checks in find about the state of the iterator, since
they're covered by the fact that we were able to obtain a FramePtr at all.
This does mean that we have to pass the pc separately. But that's symmetrical
with the insert method, so it's okay.
MozReview-Commit-ID: FgsDjHB2il4
--HG--
extra : rebase_source : cea62332ed0f138a41d4898c43945d1f981c6c98
Instead of using FrameIter::hasCachedSavedFrame, the code should instead try to
construct a FramePtr via LiveSavedFrameCache::getFramePtr, which returns a
Maybe<FramePtr>. If that is Some, then we know the frame at hand actually has a
flag, and we can test and set it.
Since the existing FrameIter::hasCachedSavedFrame screens out all wasm frames,
we change LiveSavedFrameCache::getFramePtr to do the same. However, the existing
behavior was incorrect, since wasm::DebugFrame does carry the flag; we'll fix
that in a later patch.
FrameIter::hasCachedSavedFrame asserted that jsJitFrame().isIonScripted(); this
is tested by isPhysicalIonFrame(), so that case is already covered.
MozReview-Commit-ID: 92wCc71s4nU
--HG--
extra : rebase_source : 54f60fbf298037448d9c051df3419df2a80f17d2
By design, the LiveSavedFrameCache holds the addresses of both live and dead
stack frames. This change wraps those addresses in an opaque type that can only
be compared for equality with other such values, and provides no interface to
retrieve the underlying pointer, ensuring statically that we will not
accidentally use a cache key to access memory.
MozReview-Commit-ID: 9Wom5gFVQls
--HG--
extra : rebase_source : e3dff595085973f1f10f57a67c192656c0bcd866
For the "js" crate, disable the "regex" feature to reduce binary size.
For the "u2fhid" crate, it's used only in examples. Make it a dev-dependency
so it won't be part of the Firefox build.
MozReview-Commit-ID: DY9indMqrRw
--HG--
extra : rebase_source : aa66fe1effaeca0ae35ec5dd20b33724eb3fac48
When capturing the JavaScript stack as a chain of SavedFrames, the
hasCachedSavedFrame flag on a frame indicates that the frame has an entry in
the LiveSavedFrameCache, which may hand us the SavedFrame for a previously
captured remainder of the stack, letting us stop the stack walk early.
The LiveSavedFrameCache uses AbstractFramePtr and jit::CommonFrameLayout* values
as keys. A RematerializedFrame uses an AbstractFramePtr as its key, but the
BaselineFrame we build from it has a jit::CommonFrameLayout* as its key; the two
keys are unequal. It's valuable to be able to assert that, if a frame has its
hasCachedSavedFrame flag set, then it must have an entry in the cache; to allow
that, converting a RematerializedFrame to a BaselineFrame must clear the flag,
since the BaselineFrame's key is not present.
We could instead fix up the cache entry's key, and carry over the flag, but it's
simpler to just let the cache get repopulated as needed.
MozReview-Commit-ID: 612daDJ1R4w
--HG--
extra : rebase_source : c528eafff0b1d7eeaa5f7c688a6c82631f5282a6
In JSFunction, u.wasm.native_ member must have the same type and offset as
u.native.func_. This is better accomplished by simply using func_ for both.
Further, u.wasm.jitEntry_ must alias u.native.extra.asmJSFuncIndex_. This is
better accomplished simply by making them both members of the same union.
This leaves u.wasm empty, so it can be deleted. Two static assertions about
member offsets can be removed.
MozReview-Commit-ID: 8ukNaFysWvD
--HG--
extra : rebase_source : e58a294ecd9b31592214e5e11be2f8729edb38fd
Seemed to only be used for the method that was removed in the previous patch.
MozReview-Commit-ID: 1cKpVBlxa7r
--HG--
extra : rebase_source : 357e5f9f34e418e386ac3966760241db8b7e088f
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
We're seeing startup crashes which point to data corruption in the source of
the AsyncShutdown component and module, but it's unclear whether the source of
this corruption is on disk, in memory, or in XDR data.
This change annotates crash reports with the contents of those files, so that
we can compare the actual source with the corrupted values in the generated
errors, and narrow down the source of the corruption.
MozReview-Commit-ID: 7p8y73XUGLK
--HG--
extra : rebase_source : 8e1b85df0cf69556af6f998f3d638bf2033e6ca0
extra : source : cf8613751378c8790b56131cd2a1be68573f9286
This is all dead code now that the interposition service has been removed.
MozReview-Commit-ID: H6eS26y1f0f
--HG--
extra : rebase_source : c6f94df51441a62c4fbff4be657aedc9699265f5
The TabBrowser.addProgressListener shim is the only remaining exception, since
the browser_google_behavior.js non-trivially relies on it.
MozReview-Commit-ID: Cc2ARwLkjTA
--HG--
extra : rebase_source : beea6f21dda0517c0a4c9cf09daeafcff85b93c0
We're seeing startup crashes which point to data corruption in the source of
the AsyncShutdown component and module, but it's unclear whether the source of
this corruption is on disk, in memory, or in XDR data.
This change annotates crash reports with the contents of those files, so that
we can compare the actual source with the corrupted values in the generated
errors, and narrow down the source of the corruption.
MozReview-Commit-ID: 7p8y73XUGLK
--HG--
extra : rebase_source : ad31c4fae1cb5c931e166702499dd1e56758d3e3
This adds jittering to the already existing logic for time clamping. It also exposes a
testing function allowing those interested to enable time clamping or time clamping and
jittering.
Neither (clamping nor jittering) is enabled by default.
MozReview-Commit-ID: JcHCEwRQPch
--HG--
extra : amend_source : 81d9a0c425ed2549561e5b6711f4c654614b1f38
Time Precision Reduction in the JS Engine was handled by a small bit of
duplicated logic. With Time Jittering, and general improvements to the
logic due to float fuzziness, we want to unify the logic for the JS Engine
and the browser into one location. This patch does that.
Note that this will leave the JS Shell without a time jittering implementation.
It currently has a time clamping implementation - but I'm not actually sure if
the shell is doing anything with it, because it's probably not calling
SetTimeResolutionUsec to set it up. In Bug 1440539 we will add a jitter
implementation for the shell. (And probably turn time rounding and jittering on
for it too.)
MozReview-Commit-ID: 2BTIMzE8MjW
--HG--
extra : rebase_source : db5cd6a219e1b89988f142fc22994bf816507889
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : 40b29d34e5cc99f9b8e6d5e711a03b9fe9bfa595
Lars T Hansen
Ryan VanderMeulen
Brindusan Cristian
Jason Orendorff
Nicolas B. Pierron
Dragan Mladjenovic
Bogdan Tara
Jan de Mooij
arthur.iakab
Jim Blandy
Petr Sumbera
Noemi Erli
Ted Campbell
Ciure Andrei
Luke Wagner
Aaron Klotz
Benjamin Bouvier
Dorel Luca
Csoregi Natalia
Matt Brubeck
Philip Chimento
Kannan Vijayan
Cosmin Sabou
Emilio Cobos Álvarez
Nika Layzell
Andrea Marchesini
Jeff Walden
Kris Maglione
Olli Pettay
Tom Ritter
shindli
Mike Hommey
Boris Zbarsky
Andreea Pavel