This is a follow-up to incomplete fix in bug 1382649. In that bug, I attempted to
set the process count value to the e10s rollout value, when the user unchecks
"Use default performance settings". The same function updatePerformanceSettingsBox()
is actually run during page load, resulting the user set value being changed to
e10s rollout value if the user decided to use the default process count.
Tests are written for both patches.
MozReview-Commit-ID: 4CLLcEKbS58
--HG--
extra : rebase_source : 15d2082612415363e0f69a1880efb702adcece24
extra : source : 5f81b547cd433d1a9056e5fe144ba56b13f15cc1
We are able to remove some dead code for BlockingReadIntoCache,
LastReadFailed, ClearFailedRead, Pin and Unpin have no callers at all.
MozReview-Commit-ID: KkywoKznejB
--HG--
extra : rebase_source : c6124bce6eca0b974767073fe1daf51aa50635f2
nscoord_MAX is (1<<30) so that we can check for overflow *after* adding
two nscoords. However, (nscoord_MAX + nscoord_MAX) will still overflow.
Subtracting one makes this no longer possible.
MozReview-Commit-ID: BtbQRMp5kWm
WebKit's Speedometer benchmark updates textbox to emulate text input. So it also updates caret position with focus. And, nsCaret always gets current blink time when reseting caret via LookAndFeel.
When profiling speedometer benchmark, GetCaretBlinkTime somestimes show profiling stack. This API gets data from kernel mode, so this isn't faster.
So, we should cache caret blink rate.
And when changing this rate via control panel, WM_SETTINGCHANGE is posted. So we should update this cache via this message.
MozReview-Commit-ID: IEIi25RvR1g
--HG--
extra : rebase_source : 4bc506acd67f2737cf44dc2a667c938efc7b4024
We should use AutoTArray instead because telemetry shows that the vast
majority of images loaded (95%+) contain only a single chunk when
decoding finishes. Even if part 2 of this bug increases the number of
images loaded with multiple chunks, we still call SourceBuffer::Compact
after the decode is complete, which typically will reduce the number of
chunks to 1 (unless memory is very low and we fail to consolidate the
chunks). Thus it should be rare to contain more than 1 chunk on
anything but a temporary basis, and we can easily save the malloc
overhead.
Note that SourceBuffer::AppendChunk still uses the fallible variant of
nsTArray::AppendElement.
Currently SourceBuffer::ExpectLength will allocate a buffer which is a
multiple of MIN_CHUNK_CAPACITY (4096) bytes, no matter what the expected
size is. While it is true that HTTP servers can lie, and that we need to
handle that for legacy purposes, it is more likely the HTTP servers are
telling the truth when it comes to the content length. Additionally
images sourced from other locations, such as the file system or data
URIs, are always going to have the correct size information (barring a
bug elsewhere in the file system or our code). We should be able to
trust the size given as a good first guess.
While overallocating in general is a waste of memory,
SourceBuffer::Compact causes a far worse problem. After we have written
all of the data, and there are no active readers, we attempt to shrink
the allocated buffer(s) into a single contiguous chunk of the exact
length that we need (e.g. N allocations to 1, or 1 oversized allocation
to 1 perfect). Since we almost always overallocate, that means we almost
always trigger the logic in SourceBuffer::Compact to reallocate the data
into a properly sized buffer. If we had simply trusted the expected size
in the first place, we could have avoided this situation for the
majority of images.
In the case that we really do get the wrong size, then we will allocate
additional chunks which are multiples of MIN_CHUNK_CAPACITY bytes to fit
the data. At most, this will increase the number of discrete allocations
by 1, and trigger SourceBuffer::Compact to consolidate at the end. Since
we are almost always doing that before, and now we rarely do, this is a
significant win.
SourceBuffer::Compact attempts to consolidate multiple, discrete
allocations into a single buffer, as well as trim excess capacity from a
singular allocation if we set aside too much. Using realloc lets
jemalloc (or whatever heap implementation we have) decide which is
better -- growing the existing buffer if there is sufficient free memory
contiguous with the first chunk, or allocating a new buffer entirely.
Since we were going to copy regardless, this should result either in an
improvement or the status quo. Brief empirical testing on Linux suggests
somewhere from 1/3 to 1/2 of allocations resulted in reusing the same
data pointer (and presumably avoided a copy as a result). This also has
the advantage of potentially reducing OOM errors, as it may have enough
room to satisfy an expansion, but not an entirely new buffer.
It appears to be unused, but it would be good to have some real-world data to
confirm this. A diagnostic assertion is a better choice for this than a
telemetry problem because stack-walking is such a low-level operation.
--HG--
extra : rebase_source : 1ebb96c5cce1b4a1c7ed09182c095af1b44a0f31
The reasoning behind this is that with this change, removing a non-dynamic
docshell from the document dynamically shouldn't affect the indexes which we use
for both recording and restoring data in child docshells.
MozReview-Commit-ID: JIK8GBSWDEF
All consumers of this value expect the passed-in value to be signed, and a
negative value is stored into this variable (-1) when the docshell was
dynamically added. It makes more sense for this to be signed.
MozReview-Commit-ID: 8iKDOAx7O2R
Since bug 635961, building with relro makes elfhack try to use the bss
data for a temporary function pointer. If there is not enough space for
a pointer in the bss, elfhack will complain it couldn't find the bss.
In normal circumstances, this is most likely fine. Libraries with a bss
so small that it can't fit a pointer are already too small to be
elfhacked anyways. In Firefox, the two libraries with the smallest bss
have enough space for two pointers, and aren't elfhacked (libmozgtk.so
and libplds4.so).
However, the testcase that is used during the build to validate that
elfhack works doesn't have a large enough bss on x86-64, making elfhack
bail out, and the build fail as a consequence.
This, in turn, is due to the only non-thread-local zeroed data being an
int, which is not enough to fit a pointer on x86-64. We thus make it a
size_t.
--HG--
extra : rebase_source : bca2ddbf9d4a5e8786881fc524d642c38d610227
Brian Birtles
Timothy Guan-tin Chien
Cameron McCormack
JW Wang
Servo VCS Sync
Manish Goregaokar
Wes Kocher
Makoto Kato
Daosheng Mu
Ricky Chien
Nazım Can Altınova
Bobby Holley
Ryan VanderMeulen
Gian-Carlo Pascutto
Valentin Gosu
Andrew Osmond
Sebastian Hengst
Jon Coppeard
Nicholas Nethercote
Michael Layzell
Mark Hammond
Mike Hommey
J. Ryan Stinnett