For memory efficiency in content processes, we need to be able to store
changed preferences in a separate dynamic hashtable when their values don't
match the snapshot values.
That makes iteration over the full set of preferences somewhat more
complicated, since not only do we need to iterate over two tables, but we also
need to ignore preferences in the snapshot table if they also exist in the
dynamic hashtable.
This patch solves that problem by adding an iterator helper which iterates
over values in both tables, and skips values in the static table if they also
exist in the dynamic table.
In order to support completely deleting preferences that exist in the base
table, it also ignores all dynamic entries with the None type, so that they
can completely mask deleted base table values.
MozReview-Commit-ID: LCIwyPJMByj
--HG--
extra : source : d344247b870668f53fa645e72bda4bb4309346c8
extra : histedit_source : bb670afc815f3953ccadebddd04962836569b281
The in-memory format of shared-memory preferences is significantly different
from the format used by dynamic preferences, which means that we need
different classes to access their properties.
Virtual classes would be a potential solution to this problem, but I don't
think the performance characteristics would be acceptable for preferences
code. And since the wrapper classes used for static prefs are temporary, they
would add the additional snag of figuring out how to keep a valid pointer
alive.
So, instead, this patch adds a wrapper class that can access either type of
preference, based on known type flags in a Variant. It also moves some of the
logic for deciding which preference value to return to the wrapper, so that it
doesn't need to be duplicated for each representation.
MozReview-Commit-ID: LameIIbYcD3
--HG--
extra : source : 83d98ea5ebaccded8a20929c0f3316e5618f1f76
extra : histedit_source : b3fc33ea04357e15323c7bcb1d02e73c1a9b0c76
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : source : 4b7a8a35ed956159e2f443c6211164c0cbf3d926
extra : histedit_source : 01a1160ce1107d12e8b376d4512dedb0478e447c
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : dc1c7c8015e0443eed218f826fda9f5b38b3e062%2C4cfa2f90104ca3e907607d884ac86f73ad4995bf
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
Once the majority of preferences are stored in a read-only shared map, it
won't be possible to modify the access counts in their entries. Which means we
need a separate map for the access counts.
Fortunately, this code is only active in debug builds, so it shouldn't affect
release users. And the net impact on memory usage of this patchset will still
be decidedly downward.
MozReview-Commit-ID: EuLXlMQJP1M
--HG--
extra : source : 4a8fbb472c91f13554cac3d0ea638cf9f368ff11
This uses the same event handling as the "listbox" and "listitem-checkbox" bindings that are scheduled for removal, and copies the required styles locally.
There is no need to preserve the scroll position explicitly anymore, because "richlistbox" handles scrolling like regular elements, and we don't want to persist the position when the selector is closed and reopened.
MozReview-Commit-ID: 4gYhwlprPN7
--HG--
extra : source : a92f9683c6cdaeb5541b85eb77adf46448716a7b
Support for "listbox" in preferences is also removed, in preparation for the removal of the "listbox" element and binding.
MozReview-Commit-ID: Bi2VKKi5rdk
--HG--
extra : source : 762819bac1b9efe0e939be07394bd7d293638c40
LSBUtils closes a file descriptor twice, once with fclose and then again with
close. It also does this on a background thread, during startup, which means
it tends to race with main thread code which opens files.
This patch fixes that, and also removes a work-around for the issue in the
MemMapSnapshot code.
MozReview-Commit-ID: JdDHt9ayFEl
--HG--
extra : rebase_source : 2000ede41108d6312734d8df7db98272b33528fa
extra : amend_source : 1443a596fab3e3126a22d44787adaf5e12e4587c
The preference storage in the shared memory snapshot is much more compact than
the dynamic hashtable, and is already mapped in memory, so there's no need to
keep the full hashtable in memory in the parent process after the snapshot is
created.
This patch empties the hashtable and the name string arena after the snapshot.
It also removes the accounting for preferences which have changed after init,
since those are, by definition, exactly the set of entries in the dynamic
hashtable.
MozReview-Commit-ID: L6VGq2z4foH
--HG--
extra : rebase_source : d4ba3b6a0ae3d46cf797fd6aaf4502d7a74f49c9
extra : absorb_source : e8b2648578a880d43a5a3a075e60ce1433c737ce
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : rebase_source : 93cad19e27d3aaf5d4cad358cdebd6d80b76f668
extra : absorb_source : 06cb8911c92b66f8863b5e184d88b923cdbd6adc
This patch changes our preference look-up behavior to first check the dynamic
hashtable, and then fall back to the shared map.
In order for this to work, we need to make several other changes as well:
- Attempts to modify a preference that only exists in the shared table
requires that we copy it to the dynamic table, and change the value of the
new entry.
- Attempts to clear a user preference with no default value, but which also
exists in the shared map, requires that we keep an entry in the dynamic
table to mask the shared entry. To make this work, we change the type of
these entries to None, and ignore them during look-ups and iteration.
- Iteration needs to take both hashtables into consideration. The
serialization iterator for changed preferences only needs to care about
dynamic values, so it remains unchanged. Most of the others need to use
PrefsIter() instead.
MozReview-Commit-ID: 9PWmSZxoC9Z
--HG--
extra : rebase_source : 054f4dcd534b41da889304c3c6d3365d56e8edda
extra : absorb_source : de81199e174f2d3604c803a5c016ba2f3baf3558
Since lookups in the snapshotted hashtable are currently O(log n) rather than
O(1), they're expected to be slightly more expensive than the previous
purely-dynamic lookups.
In general, I expect this not to be a major issue. The main concern is pref
cache lookups while initializing the database. Initialization in the parent
process will still always use only a dynamic hashtable, so the performance
characteristics there won't change.
In the child process, though, we'll still need to notify observers of
preferences in the snapshot when they have user values, which could require
any number of lookups at startup (though in practice probably will not).
This patch solves that problem by caching the wrapper for the current known
preference value when dispatching callbacks, and optimizing lookups for that
value when it is present.
MozReview-Commit-ID: 2CAn0rM0bE9
--HG--
extra : rebase_source : 4a7e9611efe5b554309df18f7b18ba9c807b72b2
extra : absorb_source : 185442bd69d616c2d2512df954dde7d1b54f2c30
For memory efficiency in content processes, we need to be able to store
changed preferences in a separate dynamic hashtable when their values don't
match the snapshot values.
That makes iteration over the full set of preferences somewhat more
complicated, since not only do we need to iterate over two tables, but we also
need to ignore preferences in the snapshot table if they also exist in the
dynamic hashtable.
This patch solves that problem by adding an iterator helper which iterates
over values in both tables, and skips values in the static table if they also
exist in the dynamic table.
In order to support completely deleting preferences that exist in the base
table, it also ignores all dynamic entries with the None type, so that they
can completely mask deleted base table values.
MozReview-Commit-ID: LCIwyPJMByj
--HG--
extra : rebase_source : 833abea0620f75410f9922e5d4b5cf36b84e9e50
extra : absorb_source : 89690c674120eb99ad25804408b1c3864c7b1fc8
The in-memory format of shared-memory preferences is significantly different
from the format used by dynamic preferences, which means that we need
different classes to access their properties.
Virtual classes would be a potential solution to this problem, but I don't
think the performance characteristics would be acceptable for preferences
code. And since the wrapper classes used for static prefs are temporary, they
would add the additional snag of figuring out how to keep a valid pointer
alive.
So, instead, this patch adds a wrapper class that can access either type of
preference, based on known type flags in a Variant. It also moves some of the
logic for deciding which preference value to return to the wrapper, so that it
doesn't need to be duplicated for each representation.
MozReview-Commit-ID: LameIIbYcD3
--HG--
extra : rebase_source : bf986b6008123661547949f615c8416403321835
extra : absorb_source : e86aae959325a9c3198e0259468a47a656739278
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : rebase_source : 28e8c6075bacf5f610058227a9731aeadb50f320
extra : absorb_source : f63602a163ed19fb65e26640319750fdd9b92ad1
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : rebase_source : f5de7462438e33cf4983be3fcef3c781c25ec492
extra : absorb_source : 9f9861546fc0b11333e575bb3c164dfe07575d99
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : rebase_source : e7cb96dd52380f2ed2fbd79b4e157e4efab65cb0
extra : absorb_source : ed95ed85388875353458eb65e41727e606ebf097
Once the majority of preferences are stored in a read-only shared map, it
won't be possible to modify the access counts in their entries. Which means we
need a separate map for the access counts.
Fortunately, this code is only active in debug builds, so it shouldn't affect
release users. And the net impact on memory usage of this patchset will still
be decidedly downward.
MozReview-Commit-ID: EuLXlMQJP1M
--HG--
extra : rebase_source : 6a32f03c37622093c67e7ee7a0e935d1e63c4fc8
This is the result of an execution of:
> find testing/web-platform/tests/webaudio/the-audio-api -exec sed -i "s/'TypeError'/TypeError/" {} \;
MozReview-Commit-ID: 8T0RoOobxJW
--HG--
extra : rebase_source : 12e8de86d2355ce9950fb3a985f012eb6cbf9fcd
extra : source : 30c0660089d57c5c63a1dff88a340e1e4d5779a3
extra : histedit_source : f2c4046e795a69abab5fac0913007b3db4728303
Link to the standard: https://webaudio.github.io/web-audio-api/#dom-audioparam-setvaluecurveattime
MozReview-Commit-ID: 8GwaIbQkfr2
--HG--
extra : rebase_source : ad5a2d8ebebf72d1728458e1dc180bec1e4576b1
extra : source : d752fc72a9a35fdc0ce7b8bce94b29149eaf7639
extra : histedit_source : 17a3215bebdafb6dd04aa6ddb6c62cc8672862bf
