Right now, it is a macro, which causes a warning with clang about
extraneous parentheses. Turning it into a function fixes that and is
also nicer.
MozReview-Commit-ID: KTPA9b6oeUu
--HG--
extra : rebase_source : ae063db5a4b5b14bc4a3a8f64adbbecfc897edd9
This is mostly a mimic of what we do in
GeckoCSSAnimationBuilder::FillInMissingKeyframeValues().
In Gecko we iterate over the properties just once because we can take the
index for both the synthesized start and end keyframe and easily look them up
as needed. However, in this patch we synthesize the start and end keyframes
separately and iterate over the properties twice because that's easier than
getting two indices and then later calling another FFI to dereference each of
them, and neater than getting back two pointers
MozReview-Commit-ID: 1e0R9AKzgaG
--HG--
extra : rebase_source : a37c406480c2d0ce2b8c4d4ad804622cac2083fa
This patch implement several things:
1. Implement a new constructor for nsStyleImageRequest to receive an existing
ImageValue from the caller.
2. Implement Gecko_ImageValue_Create to allow stylo to create a gecko::ImageValue
object.
3. Implement Gecko_SetXXXXImageValue to allow stylo to pass a created ImageValue
back to gecko.
MozReview-Commit-ID: 1SbW5w8FSV2
--HG--
extra : source : 63777ecf4c7138a0ce5847753a41efcbfc8e2b20
extra : intermediate-source : dced488c119da7e3ae27c903c0dcc76593d8a06d
WrapperMap::Enum::goToNext() is listed as a GC function because the *generated*
stack calls BrowserCompartmentMatcher::match() which leads a path to a FieldCall
of nsISupports.QueryInterface, however it is never the case. Add
nsContentUtils::IsExpandedPrincipal() to the ignore functions because it is more
narrowly scoped and therefore less likely to hide problems.
MozReview-Commit-ID: ACwkMtRiQk2
--HG--
extra : rebase_source : 2cadcc9f59096b4e5f693f39e2cab93da048f949
The wrappers for strings have target compartment nullptr, which are stored
separately with the other wrappers, so we can simply skip or target them.
MozReview-Commit-ID: CEgU3q7cnmB
--HG--
extra : rebase_source : 10216b58189aa7c9878dc02596e67a296f7bfbdc
Changed the type of argument |targetFilter| of NukeCrossCompartmentWrappers()
from CompartmentFilter to JSCompartment* because it is always a single target
compartment, and we can optimize the iteration not to iterate the outer map.
MozReview-Commit-ID: 7cDCgJI0H9z
--HG--
extra : rebase_source : 4973dfd4c3326bf48b78088979962e425e35030c
Now we use a flat hashmap to store CCWs, which when we want to nuke wrappers to
a target compartment, we need to iterate every single one to find them. But if
we use a 2d hashmap to store CCWs by their target compartment, we can walk
through only the wrappers that we're targeting.
MozReview-Commit-ID: 8h6wO6NLkD9
--HG--
extra : rebase_source : f6550be07979d94ba937aa5f6ac629a98df7aa44
This FFI is used by Servo_AnimationValue_GetTransform(), which needs to
handle and return none transform properly.
MozReview-Commit-ID: 49cFXE2BIbm
--HG--
extra : rebase_source : 9def5e92dc6c0b60c2fb412228a50d7e2f5eb722
We need to traverse rule tree to get the important rules, so we will not
override them if they have animations running on compositor.
MozReview-Commit-ID: 67NO2nIcUfq
--HG--
extra : rebase_source : 24a4ea4ca10e00f409d94c81acacb3db72248b3f
While we're here, also align their buckets and give them bug_numbers fields.
To change buckets for GC_MAX_PAUSE_MS we need to rename to _2. Because of
GC_MAX_PAUSE_MS' use as a historical perf metric, we need to leave it in-place
for now.
MozReview-Commit-ID: Cffo3q1pR5E
--HG--
extra : rebase_source : 9843ca718dea8694be8029530a0f8646352c5b37
WrapperMap::Enum::goToNext() is listed as a GC function because the *generated*
stack calls BrowserCompartmentMatcher::match() which leads a path to a FieldCall
of nsISupports.QueryInterface, however it is never the case. Add
nsContentUtils::IsExpandedPrincipal() to the ignore functions because it is more
narrowly scoped and therefore less likely to hide problems.
MozReview-Commit-ID: ACwkMtRiQk2
--HG--
extra : rebase_source : f4222495676f80cc74a5d38e9440cdc7a9ec0791
extra : source : 9a553b9dc92286434644838c41e8513f943f2c25
The wrappers for strings have target compartment nullptr, which are stored
separately with the other wrappers, so we can simply skip or target them.
MozReview-Commit-ID: CEgU3q7cnmB
--HG--
extra : rebase_source : d93752bf1d10c0f2dd4453ec6f96ee718b65e224
extra : source : ac4a48a831ce289295ca989fc5119611d8560ec1
Changed the type of argument |targetFilter| of NukeCrossCompartmentWrappers()
from CompartmentFilter to JSCompartment* because it is always a single target
compartment, and we can optimize the iteration not to iterate the outer map.
MozReview-Commit-ID: 7cDCgJI0H9z
--HG--
extra : rebase_source : ee9341168a28b5e6f273c512b0562ee4ddc297bc
extra : source : e80197b115673f259293d112da61c8dd9edc121e
Now we use a flat hashmap to store CCWs, which when we want to nuke wrappers to
a target compartment, we need to iterate every single one to find them. But if
we use a 2d hashmap to store CCWs by their target compartment, we can walk
through only the wrappers that we're targeting.
MozReview-Commit-ID: 8h6wO6NLkD9
--HG--
extra : rebase_source : 1bdbf3642e86ee25999fc7a4d2bec062d2efaac0
extra : source : 7e8f428a3edf506fc53bda26eacc2b64641f8346
This avoids some known hazard from replace-malloc itself, and unhides
--disable-replace-malloc hazards if there are any (and there is one from
bug 1361258), which wouldn't be caught until riding trains
(replace-malloc being only enabled on nightly).
The hazard from bug 1361258 that disappears is this one:
Error: Indirect call malloc_hook_table_t.jemalloc_thread_local_arena_hook
Location: replace_jemalloc_thread_local_arena @memory/replace/replace/ReplaceMalloc.cpp#261
Stack Trace:
jemalloc_thread_local_arena @ memory/build/replace_malloc.c#287
Gecko_SetJemallocThreadLocalArena @ layout/style/ServoBindings.cpp#2062
The new hazard from that bug is:
Error: Variable assignment jemalloc.c:arenas_map
Location: jemalloc_thread_local_arena @memory/mozjemalloc/jemalloc.c#3068
Stack Trace:
Gecko_SetJemallocThreadLocalArena @ layout/style/ServoBindings.cpp#2048
Where arenas_map is a thread-local variable, so there really is no
hazard.
--HG--
extra : rebase_source : bea3d2f862ede8c0b90775b6ec9cebb657b9b455
The movmskps SSE instruction only transfers 4 bits from the xmm
register. This work for Bool32x4 and Bool64x2 vectors, but it misses
lanes of the Bool16x8 and Bool8x16 types.
Use a pmovmskb SSE2 instruction instead which transfers 16 byte sign
bits from the xmm register. This lets us resolve even Bool8x16 lanes
correctly.
We know that the input vector is a boolean type, so each lane is known
to be either 0 or -1. There is no harm in checking too many bits of the
types with lanes wider than 8 bits. It won't affect the result.
Check the stopAtWindowProxy flag before checking IsWindowProxy(), since the flag
check is cheaper and in performance-sensitive binding code the flag is false.
MozReview-Commit-ID: 8R4tElYBXaI
--HG--
extra : rebase_source : 78d7942c3269b3d0016815a71099b4ec59587c8a
JS code often uses arrays as queues, with a loop to shift() all items, and this resulted in quadratic behavior for us. That kind of code is much faster now.
PromiseObject now has a createSkippingExecutor function that avoids the need for a dummy executor for internally created promises.
MozReview-Commit-ID: IEzNwMYSdde
The shell has a very basic implementation of Promise job queue handling. This patch moves it into the engine, exposed through friendapi functions. The motivation is that I want to write JSAPI tests for streams, which requires Promise handling. The test harness would need essentially a copy of the shell's Promise handling, which isn't nice.
To be clear, the default implementation isn't used automatically: the embedding has to explicitly request it using js::UseInternalJobQueues.
MozReview-Commit-ID: 6bZ5VG5mJKV
TSAN messes up the wasm signal handler on try builders.
--HG--
extra : rebase_source : c161c4eebc1f43daa0eeae13218b47ece13595c4
extra : histedit_source : 2cf2dad71d822fc583da2b5b633f8f21f05fa66a
One jstest was found to run more slowly under tsan, so add it to the cgc-jittest-timeouts.txt bucket.
Several jit-tests expect to timeout, and are annotated with an expected status code. Currently, we have to force tsan to report a zero status if it finds an error, since otherwise it will cause lots of tests to fail (due to hitting a tsan-detectable problem.) But those zero exit statuses cause the test to fail. Add --unusable-error-status to treat those as passing.
--HG--
extra : rebase_source : 37e9b863ecb6929da0de2a2d947ec31f6ba15d78
extra : histedit_source : c33dacaa0ecc117f17b57cf0dc5ba6c5b775d6ce
The shell has a very basic implementation of Promise job queue handling. This patch moves it into the engine, exposed through friendapi functions. The motivation is that I want to write JSAPI tests for streams, which requires Promise handling. The test harness would need essentially a copy of the shell's Promise handling, which isn't nice.
To be clear, the default implementation isn't used automatically: the embedding has to explicitly request it using js::UseInternalJobQueues.
MozReview-Commit-ID: DwtPsJ0uMtP
This annotates vsprintf-like functions with MOZ_FORMAT_PRINTF. This may
provide some minimal checking of such calls (the GCC docs say that it
checks for the string for "consistency"); but in any case shouldn't
hurt.
MozReview-Commit-ID: HgnAK1LiorE
--HG--
extra : rebase_source : 9c8d715d6560f89078c26ba3934e52a2b5778b6a
FlowGraphSummary walks the bytecode linearly, assuming that a branch
instruction will always be visited before the branch's target. However,
this is not the case for JSOP_LOOPHEAD, leading to an incorrect line
number (-1). This patch changes it to instead reuse the location of the
previous opcode, which is correct in the case of a loop head.
MozReview-Commit-ID: 5OmLmSk2uSn
--HG--
extra : rebase_source : fb773071855bb481747469833ec820ef202d1205
Flushing the cache at startup is already handled automatically by the
AppStartup code, which removes the entire startupCache directory when
necessary. The add-on manager requires being able to flush the cache at
runtime, though, for the sake of updating bootstrapped add-ons.
MozReview-Commit-ID: LIdiNHrXYXu
--HG--
extra : source : 8f4637881ddc42a948c894e62c8486fe8677a938
extra : histedit_source : e69395a2b87b2b0edb394686ed6ee24731ba9fb8
One of the things that I've noticed in profiling startup overhead is that,
even with the startup cache, we spend about 130ms just loading and decoding
scripts from the startup cache on my machine.
I think we should be able to do better than that by doing some of that work in
the background for scripts that we know we'll need during startup. With this
change, we seem to consistently save about 3-5% on non-e10s startup overhead
on talos. But there's a lot of room for tuning, and I think we get some
considerable improvement with a few ongoing tweeks.
Some notes about the approach:
- Setting up the off-thread compile is fairly expensive, since we need to
create a global object, and a lot of its built-in prototype objects for each
compile. So in order for there to be a performance improvement for OMT
compiles, the script has to be pretty large. Right now, the tipping point
seems to be about 20K.
There's currently no easy way to improve the per-compile setup overhead, but
we should be able to combine the off-thread compiles for multiple smaller
scripts into a single operation without any additional per-script overhead.
- The time we spend setting up scripts for OMT compile is almost entirely
CPU-bound. That means that we have a chunk of about 20-50ms where we can
safely schedule thread-safe IO work during early startup, so if we schedule
some of our current synchronous IO operations on background threads during the
script cache setup, we basically get them for free, and can probably increase
the number of scripts we compile in the background.
- I went with an uncompressed mmap of the raw XDR data for a storage format.
That currently occupies about 5MB of disk space. Gzipped, it's ~1.2MB, so
compressing it might save some startup disk IO, but keeping it uncompressed
simplifies a lot of the OMT and even main thread decoding process, but, more
importantly:
- We currently don't use the startup cache in content processes, for a variety
of reasons. However, with this approach, I think we can safely store the
cached script data from a content process before we load any untrusted code
into it, and then share mmapped startup cache data between all content
processes. That should speed up content process startup *a lot*, and very
likely save memory, too. And:
- If we're especially concerned about saving per-process memory, and we keep
the cache data mapped for the lifetime of the JS runtime, I think that with
some effort we can probably share the static string data from scripts between
content processes, without any copying. Right now, it looks like for the main
process, there's about 1.5MB of string-ish data in the XDR dumps. It's
probably less for content processes, but if we could save .5MB per process
this way, it might make it easier to increase the number of content processes
we allow.
MozReview-Commit-ID: CVJahyNktKB
--HG--
extra : source : 1c7df945505930d2d86a076ee20807104324c8cc
extra : histedit_source : 75e193839edf727874f01b2a9f6852f6c1f087fb%2C3ce966d7dcf2bd0454a7d673d0467097456bd782
When decoding off-thread, we can't safely access the JS runtime to get the
current JS version, and doing so causes failed assertions.
MozReview-Commit-ID: Lra437aa8SM
--HG--
extra : source : 16259c1af36e138881d18a3f8b0a803f5d4fc3ec
Flushing the cache at startup is already handled automatically by the
AppStartup code, which removes the entire startupCache directory when
necessary. The add-on manager requires being able to flush the cache at
runtime, though, for the sake of updating bootstrapped add-ons.
MozReview-Commit-ID: LIdiNHrXYXu
--HG--
extra : rebase_source : e5b16490f47e20c78d081ad03dec02c6b2874fc3
extra : absorb_source : 6cd94504c8247f375161b2afdca5c61d59cf8f01
One of the things that I've noticed in profiling startup overhead is that,
even with the startup cache, we spend about 130ms just loading and decoding
scripts from the startup cache on my machine.
I think we should be able to do better than that by doing some of that work in
the background for scripts that we know we'll need during startup. With this
change, we seem to consistently save about 3-5% on non-e10s startup overhead
on talos. But there's a lot of room for tuning, and I think we get some
considerable improvement with a few ongoing tweeks.
Some notes about the approach:
- Setting up the off-thread compile is fairly expensive, since we need to
create a global object, and a lot of its built-in prototype objects for each
compile. So in order for there to be a performance improvement for OMT
compiles, the script has to be pretty large. Right now, the tipping point
seems to be about 20K.
There's currently no easy way to improve the per-compile setup overhead, but
we should be able to combine the off-thread compiles for multiple smaller
scripts into a single operation without any additional per-script overhead.
- The time we spend setting up scripts for OMT compile is almost entirely
CPU-bound. That means that we have a chunk of about 20-50ms where we can
safely schedule thread-safe IO work during early startup, so if we schedule
some of our current synchronous IO operations on background threads during the
script cache setup, we basically get them for free, and can probably increase
the number of scripts we compile in the background.
- I went with an uncompressed mmap of the raw XDR data for a storage format.
That currently occupies about 5MB of disk space. Gzipped, it's ~1.2MB, so
compressing it might save some startup disk IO, but keeping it uncompressed
simplifies a lot of the OMT and even main thread decoding process, but, more
importantly:
- We currently don't use the startup cache in content processes, for a variety
of reasons. However, with this approach, I think we can safely store the
cached script data from a content process before we load any untrusted code
into it, and then share mmapped startup cache data between all content
processes. That should speed up content process startup *a lot*, and very
likely save memory, too. And:
- If we're especially concerned about saving per-process memory, and we keep
the cache data mapped for the lifetime of the JS runtime, I think that with
some effort we can probably share the static string data from scripts between
content processes, without any copying. Right now, it looks like for the main
process, there's about 1.5MB of string-ish data in the XDR dumps. It's
probably less for content processes, but if we could save .5MB per process
this way, it might make it easier to increase the number of content processes
we allow.
MozReview-Commit-ID: CVJahyNktKB
--HG--
extra : rebase_source : 2ec24c8b0000f9187a9bf4a096ee8d93403d7ab2
extra : absorb_source : bb9d799d664a03941447a294ac43c54f334ef6f5
When decoding off-thread, we can't safely access the JS runtime to get the
current JS version, and doing so causes failed assertions.
MozReview-Commit-ID: Lra437aa8SM
--HG--
extra : rebase_source : 268fc90f390cf6436f3e8a1368a62fdf274d6f8d
The algorithm:
1. Keep a list of all sloppy functions-in-block FunctionBoxes on the
innermost scope.
2. When the scope exits, we'll know all its declared names. Check for possible
early errors for declaring the FiBs as vars. If no early error would occur,
a. If the innermost scope is the var scope, declare the synthesized
var and mark the FunctionBox as an Annex B function.
b. Otherwise, add the FunctionBox to the enclosing scope's list of
sloppy FiBs.
The JS shell, for testing purposes, allows passing in an OOB column
number, which offsets all token positions by column. These positions
need to be de-offset before being saved as offsets into the
ScriptSource buffer in the script structures.
Callable prologues/epilogues use the ABINonArgReg0 register as a scratch
register, which is non-volatile on ARM. This means it can get clobbered.
Instead, just preserve it manually.
--HG--
extra : rebase_source : 290f2a7a5cf2ad0240cf9775b411615f94ac5a16
This combines InIRGenerator with HasOwnIRGenerator.
MozReview-Commit-ID: 7FQX5YmVrM7
--HG--
extra : rebase_source : 9b0e735e303f6fa57d4407bec5b81bc8307d365a
To make Promise-related JSAPI functions easier to use, this patch unwraps handed-in Promise objects automatically. Some functions don't unwrap, mostly debugging-related ones and, notably, JS::IsPromiseObject. The latter doesn't unwrap in order to stay conservative: if JSAPI-using code uses IsPromiseObject to verify that an object is a Promise, it should always be fine to say "no".
MozReview-Commit-ID: 7DuCqCj95JR
--HG--
extra : rebase_source : 86e5b837c68fcbd1c1930dffefc22856b02cf3b1
André Bargull
Steve Fink
Andrew McCreight
Xidorn Quan
Ted Campbell
Sebastian Hengst
Kris Maglione
Hiroyuki Ikezoe
Jan de Mooij
cku
Ryan VanderMeulen
Ting-Yu Chou
Manish Goregaokar
Boris Chiou
Chris H-C
Mike Hommey
Sean Stangl
Jakob Stoklund Olesen
Carsten "Tomcat" Book
Iris Hsiao
Nicolas B. Pierron
Till Schneidereit
Wes Kocher
Luke Wagner
Benjamin Bouvier
Milan Sreckovic
Ravi Shankar
Shu-yu Guo
Leo Balter
kedziorski.lukasz@gmail.com
Jon Coppeard
Alexandre Poirot
Tom Tromey
Andrea Marchesini
Gary Kwong
Cameron McCormack
Lars T Hansen
David Major
Nathan Froyd
Jeff Walden
Eric Rahm