Jemalloc 4 purges dirty pages regularly during free() when the ratio of dirty
pages compared to active pages is higher than 1 << lg_dirty_mult. We set
lg_dirty_mult in jemalloc_config to limit RSS usage, but it also has an impact
on performance.
So instead of enforcing a high ratio to force more pages being purged, we keep
jemalloc's default ratio of 8, and force a regular purge of all dirty pages,
after cycle collection.
Keeping jemalloc's default ratio avoids cycle-collection-triggered purge to
have to go through really all dirty pages when there are a lot, in which case
the normal jemalloc purge during free() will already have kicked in. It also
takes care of everything that doesn't run the cycle collector still having
a level of purge, like plugins in the plugin-container.
At the same time, since jemalloc_purge_freed_pages does nothing with jemalloc 4,
repurpose the MEMORY_FREE_PURGED_PAGES_MS telemetry probe to track the time
spent in this cycle-collector-triggered purge.
We're changing the definition of each of the use counter histograms.
Therefore, they need new names, so as to not throw wrenches into the
server-side machinery. This renaming is the most straightforward way to
do things and similar to how we have renamed other histograms before.
These histograms will be used in conjunction with the revised use
counter histograms to ascertain the number of pages that don't use
particular features. The associated comment in nsDocument.cpp explains
how things work.
The printing back-end used to be in charge of opening up an error dialog
when things go wrong with printing. Now we fire an event and let PrintUtils
do the work of showing the error message. This has the added bonus of making
the error messages work with e10s.
--HG--
extra : commitid : LPWfOvQ1TaI
extra : rebase_source : fa6f71e6c9cf9062feb2bd1d0f362680899385fc
This changeset modifies the ThreadSafeChromeUtils::saveHeapSnapshot webidl
method to return the path to the core dump file where the heap snapshot was
serialized rather than taking the file path as a parameter.
By removing the ability for callers to choose a path, we pave the way for
enabling taking heap snapshots in sandboxed child processes (e10s, fxos) that do
not have access to the filesystem directly and must be handed a file descriptor
over IPDL. Additionally, the devtools API consumers were not taking advantage of
the ability to choose a file path, and always saving heap snapshots into the
temp directory anyways.
When a lightweight theme is active the default theme is the selected skin but
the default theme's addon object is marked as inactive (to deal with the horror
of only allowing the user to select a single theme through the UI).
During startup we should only switch back to the default theme if there is a
non-default skin selected that we didn't see.
--HG--
extra : commitid : 8v5gChgFbgw
extra : rebase_source : 277807f800c98336c624718dc09b8ed44a25f201
Added tests to ensure negative and positive delays are shown correctly
and that the timeScale window is computed correctly.
Also added a test to ensure that animations with the same name but
different nodes don't override each others in the UI.
This commit also cleans up a lot of exceptions that were thrown while
tests were running. These exceptions were due to pending protocol requests
when tests ended.
--HG--
extra : commitid : FAEjthxcFYj
extra : rebase_source : 090d41fce18e147b109f92afa81b4f2f76295348
rs=smaug on the webidl change
IGNORE IDL due to only adding a const
--HG--
extra : commitid : zI9Hpg9cZ6
extra : rebase_source : 8a2bf373dd9ed2c08ef9229ccd7dfff4fe1b30f7
extra : histedit_source : e0b5ba801b8c9912378e90779c42e99f4604276d
This adds two new directory install locations. One contains the default system
add-ons that ship with the application, the other contains system add-on that
will eventually be updatable at runtime.
The updatable location tracks the expected list of add-ons in a pref. and only
returns add-ons from that list when asked for its list of add-ons.
After processFileChanges has scanned all add-ons and updated the database it
checks if the updated system add-ons match the expected set. If not we ignore
those add-ons when working out which add-ons should be visible. If they do match
then we ignore the app-shipped system add-ons when working out which are
visible.
--HG--
extra : commitid : LYCHZGSoGwj
extra : rebase_source : c9bc96b36d23ba9b4374adead9b59059ccb02f39
This is a useful method to expose on the AnimationsActor so that the front-end
can play or pause the list of animations currently displayed in the UI without
introducing synchronization offsets. This way all animations are paused
synchronously on the server instead of having to request pausing each animation
one by one from the front-end.
--HG--
extra : commitid : GOlqvpCVgrA
extra : rebase_source : 71d436d18907a97b6b287f4bf7df93d2b6ee3796
Makes sure that add-on objects always have the _installLocation property for
the location they will be installed into so that isUsableAddon can test for the
right signature.
--HG--
extra : transplant_source : %9C%C1%AC%13%82%F2%94%18%9F%BC%CD%0C%FC%F65B%0DY%86%3F
Most directory install locations are immutable at runtime. Only the profile
location can be installed into and uninstalled from. The system add-on locations
will be immutable as well but also be extended with some extra functionality so
it is useful to split the immutable parts out into a shared class that both
the mutable location and eventually system add-on locations can inherit from.
--HG--
extra : commitid : 4JAbEmPbxAc
extra : rebase_source : 136e4143a24f09dc88f4db1b5dc450568e40799a
Normal directory install locations expect add-ons to exist on disk with the
naming convention "<id>.xpi". Originally system add-ons were going to do
something different so I started working on this. In the end it is unnecessary
but this work did reveal some cases where _sourceBundle wasn't being updated
for add-ons and removing most of these assumptions is still valuable.
--HG--
extra : commitid : 81LpRFeugL5
extra : rebase_source : 8b532ee58e57194889fffd8d9558718e1b551bac
As part of this move, HOST_NSPR_MDCPUCFG needed to be changed to get the quoting right.
--HG--
extra : commitid : J26MhSiPq9g
extra : rebase_source : 81c5b98371042803741ddace8d01b0097757dff3
The add-ons manager recognises the notion of "install locations". Each location
can contain add-ons that are installed in the application. There are two main
types, directory locations which exist as a directory somewhere in the
filesystem and registry locations which exist in the Windows registry. The
profile location is the one where add-ons installed through the UI exist, the
other locations are for add-ons that are bundled with the application,
installed by the OS or by third-party applications.
Install locations have priorities. The profile location has the highest priority
then the others gradually lower priorities. When an add-on exists in more than
one install location the version in the highest priority location is the one
that is visible and can be active in the application. We still retain details
about the other versions in the database.
On every startup the add-ons manager scans over these install locations to see
if the set of installed add-ons has changed at all. A very quick check is done
to see if the more thorough check in processFileChanges (which synchronously
loads the add-ons database and install manifests for the add-ons) is needed.
The job of processFileChanges is to load information about all the add-ons and
update the add-ons database to match. It has to decide which add-ons to make
visible, track what changes were made to the visible set of add-ons and call
restartless add-ons install and uninstall scripts.
The original version of processFileChanges attempted to optimise this by doing
all of the work in a single loop over the add-ons in the locations. This mostly
worked but made certain situations difficult to handle (see bug 607818 f.e.).
There isn't much need for this level of optimisation. We're already in a slow
pass and once all the data is loaded off the disk looping over it is fast.
This changeset moves processFileChanges into the XPIProviderUtils file which is
lazy loaded when necessary. While most of the code is the same it instead does
one loop to update the database and gather information, then a second loop to
update add-on visibility, record changes and call bootstrap scripts.
--HG--
extra : commitid : CRFjjhiI4Pi
extra : rebase_source : 85091024e331dce72b9d704ca7a962a30d4b8407
Bill McCloskey
Mike Hommey
Seth Fowler
Jason Orendorff
Christoph Kerschbaumer
Wes Kocher
Phil Ringnalda
David Anderson
Patrick Brosset
Carsten "Tomcat" Book
Georg Fritzsche
Jordan Santell
Alexandre Lissy
Riadh Chtara
Gijs Kruitbosch
Justin Dolske
Nathan Froyd
Matteo Ferretti
Bernardo P. Rittmeyer
J. Ryan Stinnett
Neil Deakin
Richard Barnes
Jared Wein
Patrick McManus
Mike Conley
Gervase Markham
Daosheng Mu
Nicholas Nethercote
Chris Pearce
Kate McKinley
Randall Barker
Russ Nicoletti
Nick Fitzgerald
Michael Ratcliffe
Dão Gottwald
Jacek Caban
Ehsan Akhgari
Dave Townsend
Alexandre Poirot
Florent Fayolle
Bradley Garlick
Michael Layzell
Brian Grinstead
Nigel Babu
Kaustabh Datta Choudhury
Florian Quèze
Trevor Rowbotham
Andrew McCreight
Nick Robson
Matthew Noorenberghe
Milan Sreckovic
Milan Sreckovic
Mike Shal
Ted Mielczarek
Andrea Marchesini
Kan-Ru Chen
Kit Cambridge
JW Wang
Marco Bonardo