```
implement size hint for
more iterators because why
not we like fast things
```
Source-Repo: https://github.com/servo/servo
Source-Revision: bb2030a49314433c1b31f853e4fa50afa241b596
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : fb164a6e8e51ebba14d97ee7600567b3b517dc30
The bin-unused count in memory reports indicates how much memory is
used by runs of small and sub-page allocations that is not actually
allocated. This is generally thought as an indicator of fragmentation.
While this is generally true, with the use of thread local arenas by
stylo, combined with how stylo allocates memory, it ends up also being
an indicator of wasted memory.
For instance, over the lifetime of an AWSY iteration, there are only a
few allocations that ends up in the bucket for 2048 allocated bytes. In
the "worst" case, there's only one. But the run size for such
allocations is 132KiB. Which means just because we're allocating one
buffer of size between 1024 and 2048 bytes, we end up wasting 130+KiB.
Per thread.
Something similar happens with size classes of 512 and 1024, where the
run size is respectively 32KiB and 64KiB, and where there's at most a
handful of allocations of each class ever happening per thread.
Overall, an allocation log from a full AWSY iteration reveals that there
are only 448 of 860700 allocations happening on the stylo arenas that
involve sizes above (and excluding) 512 bytes, so 0.05%.
While there are improvements that can be done to mozjemalloc so that it
doesn't waste more than one page per sub-page size class, they are
changes that are too low-level to land at this time of the release
cycle. However, considering the numbers above and the fact that the
stylo arenas are only really meant to avoid lock contention during the
heavy parallel work involved, a short term, low risk, strategy is to
just delegate all sub-page (> 512, < 4096) and large (>= 4096) to the
main arena. Technically speaking, only sub-page allocations are causing
this waste, but it's more consistent to just delegate everything above
512 bytes.
This should save 132KiB + 64KiB = 196KiB per stylo thread.
--HG--
extra : rebase_source : c7233d60305365e76aa124045b1c9492068d9415
Until bug 1361258, there was only ever one mozjemalloc arena, and the
number of dirty pages we allow to be kept dirty, fixed to 1MB per arena,
was, in fact, 1MB for an entire process.
With stylo using thread local arenas, we now can have multiple arenas
per process, multiplying that number of dirty pages.
While those dirty pages may be reused later on, when other allocations
end up filling them later on, the fact that a relatively large number of
them is kept around for each stylo thread (in proportion to the amount of
memory ever allocated by stylo), combined with the fact that the memory
use from stylo depends on the workload generated by the pages being
visited, those dirty pages may very well not be used for a rather long
time. This is less of a problem with the main arena, used for most
everything else.
So, for each arena except the main one, we decrease the number of dirty
pages we allow to be kept around to 1/8 of the current value. We do this
by introducing a per-arena configuration of that maximum number.
--HG--
extra : rebase_source : 75eebb175b3746d5ca1c371606cface50ec70f2f
Due to content sandbox, NSPrintJobSavingURL will throws an exception on content process. So we don't use NSPrintJobSavingURL on content process and print.print_via_parent=true.
Also, even if chrome process, SetToFileName should store file name to mToFileName. Because SetToFileName uses mToFileName.
MozReview-Commit-ID: J7vlOG0gyGP
--HG--
extra : rebase_source : dfda2f625ca9dabefe131e40424609a2b921d430
Mostly just threading the TextDrawTarget deeper into the code to use a boolean.
A lot of places are trying to optimize away invisible text!
MozReview-Commit-ID: 89sDAwUv0HA
--HG--
extra : rebase_source : 8d800702232aec6626a33f2d6be893708d0bbfee
It logically belongs there, and the only reason it wasn't there before we were
working around other stuff. Now it's needed to share UA stylesheets across documents.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1ab705b0265cac358c3bebb3fec8cbac089f015d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 1e77773a569f810d62dc1f3997817dd86feff377
This isn't a super essential feature, and is just a change to try to bring us in
line with chromium and the spec. As this has apparent web compat issues, and
DataTransfer is a hard to test area, this patch moves the changes behind a pref,
which we can come back to turning on after we ship 57.
Previously the code looped and yielded between each loop. This caused the
DataTransfer to be cleared before the read completed.
This splits the loop into 2 sections such that we read all important data from
the DataTransfer before it is cleared.
From the crashes associated with bug 1389021, we know that some
compositor thread IPDL owners are not being cleaned up properly. We do
not know which protocols are causing the problem, so we temporarily will
annotate the logs with the ownership status. This should be limited to
under a dozen instances of the protocols.
This change will be backed out after a few builds are produced with it
and we see the first crash reports with the relevant data.
Corey Farwell
Chris Peterson
Mike Hommey
Makoto Kato
Daosheng Mu
Alexis Beingessner
suneet
Mark Striemer
Ryan VanderMeulen
Emilio Cobos Álvarez
Sebastian Hengst
Ben Kelly
Alexander Surkov
Wes Kocher
ffxbld
Peter Moore
Christoph Kerschbaumer
Michael Layzell
Andrew Osmond
Grigory Kruglov
Matt Howell
Geoff Brown
Will Wang
Boris Zbarsky
Jeff Muizelaar
Yury Delendik
Shawn Huang
Andrea Marchesini
David Anderson