Fixes a hazard introduced by allowing the analysis to correctly see through more of the callgraph.
--HG--
extra : topic : hazard
extra : rebase_source : a2b20f3a4c5127c502c1402ca9abbd1e2ad0d382
TC39 has decided to rename Atomics.wake as the more conventional
Atomics.notify. The webcompat fallout from this should be roughly
zero, as browser currently have disabled SAB as a result of the
Spectre kerfuffle.
This patch introduces Atomics.notify, and changes a number of names in
the code and in test cases as a result, but retains Atomics.wake as an
alias until we're happy that we don't need it.
A note on nomenclature used in the code: Though Atomics.notify
/notifies/ the target agent, we still say that the agent was /woken/
by the notification if it becomes schedulable. An agent can be
notified without being woken in obscure implementation-specific
settings, normally having to do with waiting in interrupt handlers.
Also fixes a completely blatant and impossible-not-to-discover bug in
tests/shell/futex.js. Do we never run shell tests marked "slow"?
This makes me nervous.
--HG--
extra : rebase_source : db86f1c1b92ad831d081dd606e057d2919deb466
extra : histedit_source : eadfd80f068f7dec8c34f5cdfaadeecd31d001b4
When enabling the tracelogger, it will automatically spew the data to disk in the location specified by TLDIR or /tmp, if undefined. However, there needs to be a way to enable the tracelogger without spewing so that we can write this data as part of the gecko profiler JSON output, and ultimately visualized with perf.html.
Differential Revision: https://phabricator.services.mozilla.com/D3138
--HG--
extra : moz-landing-system : lando
Atomic operations are stress-tested by having multiple workers work on
the same location in ways that would reveal non-atomicity in an
incorrect result.
We run these tests only on native implementations, not on simulators.
Our simulators don't implement atomicity well.
This patch has the bare minimum, testing multiple agents that perform
the same operation. It's possible to do more, notably, to combine
different operations.
--HG--
extra : rebase_source : ddc2f611e87d099d15eedaec81304056b2ed14ac
extra : histedit_source : 466994c25d0d33986c41f5420bcc1dfa235f08fe
Normally ReadScalar uses memcpy from the source stream to the
destination object. This is only well-defined if the destination
argument is a POD type, which ExprType is not. So specialize
ReadScalar for ExprType and make the memcpy target the data payload in
that type instead.
--HG--
extra : rebase_source : 20df55aa1358e2bbceb3a06a386732897abaff27
extra : histedit_source : 1097641e4da9d4f656d7e2900878a116cd080efb
The pod member needs to be POD but has members that have evolved no
longer to be POD - a ValType and a LitVal. We work around the problem
locally by using ValType's representation type PackedTypeCode to
represent types, and by specializing LitVal as LitValPOD for use in
this structure.
--HG--
extra : rebase_source : 76194d811f28316ad890d6c9f1978773f3570838
Currently lookupOrAdd() will allocate if the table has no storage. But it
doesn't report an error if the allocation fails, which can cause problems.
This patch changes things so that lookupOrAdd() doesn't allocate when the table
has no storage. Instead, it returns an AddPtr that is not *valid* (its mTable
is empty) but it is *live*, and can be used in add(), whereupon the allocation
will occur.
The patch also makes Ptr::isValid() and AddPtr::isValid() non-public, because
the valid vs. live distinction is non-obvious and best kept hidden within the
classes.
--HG--
extra : rebase_source : 95d58725d92cc83332e27a61f98fa61185440e26
Bug 1484382 - Use mozilla::ScopeExit in jit/JitFrames.cpp
Bug 1484382 - Use mozilla::ScopeExit in vm/TypeInference.cpp
Bug 1484382 - Use mozilla::ScopeExit in jit/JitcodeMap.cpp
Bug 1484382 - Use mozilla::ScopeExit in jit/JitFrames.cpp
Differential Revision: https://phabricator.services.mozilla.com/D3685
--HG--
extra : moz-landing-system : lando
As the comment for SetJitExceptionHandler makes clear, the
infrastructure we have for generating unwind information on 64-bit
Windows is only necessary to permit Breakpad to generate crash reports.
We don't even have crash reporting for our non-existent AArch64 Windows
builds, and it will likely take us some time to make the necessary
changes in Breakpad and elsewhere. In addition, the unwind information
format is completely different on AArch64, and there's no decent
documentation on it yet.
Given all of this, the easiest way forward right now is to simply
disable this code to get things compiling. We can reenable it later
once we understand how to add appropriate support.
