This functionality already exists, so it is just a matter of threading
an extra bool around. This patch should not actually change the behavior
anywhere.
The goal of this is to consider using it for AWSY. Currently AWSY
asks every process to minimize memory usage at once, but with
this option the minimization will be batched along with the memory
reports, which should make it less likely to overwhelm the system
when there are a lot of content processes.
Differential Revision: https://phabricator.services.mozilla.com/D87475
To be honest, it's still a mystery why we observed a regression in
sessionrestore_no_auto_restore in bug 1658732. The regression won't reproduce
on profiled runs, and the bad recordings happen before the supposedly offending
code ever actually runs. It feels most likely that it is a more or less random
confluence of factors causing a regression; however, 33% is too large of a
number to ignore.
The changes in this patch do not seem to yield the same regression, and they
are arguably more correct anyway. Instead of simply turning off the cache after
startup is finished, we simply avoid blocking waiting for the write from inside
GetBuffer. This way, if the write is not getting in the way of GetBuffer, we
can still benefit from a cached version of whatever it is we're looking for.
Differential Revision: https://phabricator.services.mozilla.com/D87221
ARM has a common calling standard for all operating systems running on
ARM64, and Apple platforms almost follow it, except for a few rules which
aren't relative to xptcall, plus one significant exception: arguments
spilled to the stack only occupy the space they need to. So in the common
calling standard, a `uint16_t` would occupy eight bytes when it is passed on
the stack, whereas on Apple platforms, it only occupies two bytes.
Original patch by @froydnj.
Differential Revision: https://phabricator.services.mozilla.com/D87007
Through some sleight-of-hand, we can treat argument allocation in aarch64's
xptcinvoke exactly the same for integer and floating-point arguments. This
change isn't so important now, but it centralizes the allocation of stack
slots, which is important for making this code handle Apple's calling
conventions.
Depends on D87005
Differential Revision: https://phabricator.services.mozilla.com/D87006
These files will all compile, but things will break at runtime because the
convention for stack arguments is slightly different on Darwin. We'll fix
that in the next patch or two.
Depends on D87004
Differential Revision: https://phabricator.services.mozilla.com/D87005
We avoid going through Substring which imposes a limit on the string length of
INT32_MAX and failing a MOZ_RELEASE_ASSERT otherwise.
This adds a new `Base64EncodeAppend` function that takes 8-bit char input and
produces 16-bit char output, and appends to an existing string, which is what
we need here to avoid doing a large copy. Base64EncodeHelper is generalized
to accomodate for that.
So in addition to fixing the defect, this also optimizes performance and
memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D87413
nsTArray_Impl::Assign/operator= copying from another array cause code bloat by
using ReplaceElementsAtInternal without exploiting the knowledge that the whole
array is being replaced. Since for many instances of the class template, this
is the only ReplaceElementsAtInternal call being done, this unnecessary bloats
the generated code. Apart from that, it is suboptimal at runtime due to
unnecessary checks.
Furthermore, the implementation of ReplaceElementsAtInternal may unnecessarily
relocate the existing elements before destroying them if the storage needs to
be reallocated. While this could be optimized in ReplaceElementsAtInternal as
well, it is simpler to do so in the specialized AssignInternal that is now
introduced.
Differential Revision: https://phabricator.services.mozilla.com/D86723
These have been cargo-culted all over the place and they are totally
unnecessary, not to mention potentially confusing. Let's delete them.
Differential Revision: https://phabricator.services.mozilla.com/D86978
This is a speculative fix for a crash we're seeing due to xul.css ostensibly
not existing. The theory is that xul.css does in fact exist and the cached
zip central for the omnijar is simply corrupt in some way. If it is corrupt in
this way, then there is a bigger issue, and we need to investigate deeper.
However, the benefit of this approach is that it is a very small and contained
patch which should be simple to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D86829
This code was there to prevent stuff like bug 424377, but nowadays clone
documents are data documents to begin with, so they can't load scripts.
Differential Revision: https://phabricator.services.mozilla.com/D86948
The perfecthash module will instead try to sit in an infinite loop, so catching
this early is essential for giving better error messages.
Differential Revision: https://phabricator.services.mozilla.com/D85655
This change updates the unix implementation of nsLocalFile
Set/GetLastModifiedTime methods to improve the precision of file modification
times from a 1 second resolution to a 1 millisecond resolution.
Differential Revision: https://phabricator.services.mozilla.com/D86238
This changes the StartupCache::PutBuffer call from Omnijar to use a
fallibly allocated buffer, to reduce OOM crashes. We can/should broaden the
scope of this, but this is a simple initial change to mitigate the OOM
crashed introduced with bug 1627075.
Differential Revision: https://phabricator.services.mozilla.com/D86067
We now use `PARAM_BUFFER_COUNT` for slightly more stuff, so update the
comment describing its two uses. Experimentation has also shown that we can
decrease the count slightly, which is a tiny tiny win.
Differential Revision: https://phabricator.services.mozilla.com/D86214
Now that we've statically ensured everything fits into the stack-allocated
array(s), we can delete the case that handled dynamic allocation.
Differential Revision: https://phabricator.services.mozilla.com/D86213
We used to not be able to do something like this, and therefore our xpidl
calling code had to be fully general. But now that we know all possible
xpidl methods at build time, we can ensure that the number of parameters
does not exceed some bound. And we choose that bound to be the maximum
number of stack-allocated parameters our calling code supports.
Differential Revision: https://phabricator.services.mozilla.com/D86212
There's no reason to have a different count depending on whether we have
floating-point registers or not; xpidl functions will have the same number
of parameters regardless. This change also synchronizes soft-float PPC with
every other architecture.
Differential Revision: https://phabricator.services.mozilla.com/D86210
David Teller
Chris Fronk
Andrew McCreight
Honza Bambas
Simon Giesecke
Doug Thayer
Bogdan Tara
Mike Hommey
Nathan Froyd
Erik Nordin
Nika Layzell
alwu
Zeke Medley
Mihai Alexandru Michis
Gerald Squelart
Emilio Cobos Álvarez
Joshua Cranmer
Razvan Maries
Keefer Rourke
Jorg K