The logging interface is moved to xpcom/base, a LogModule wrapper for PR_Log is
added, a thread-safe LogModuleManager is added, and a LazyLogModule class used
to lazily load log modules in a thread-safe manner is added.
--HG--
rename : xpcom/glue/Logging.h => xpcom/base/Logging.h
extra : rebase_source : 89b76664d9477e2c894448cdea4dae1c61f8ca24
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This commit was generated using the following script, executed at the
top level of a typical source code checkout.
# Don't modify select files in mfbt/ because it's not worth trying to
# tease out the dependencies currently.
#
# Don't modify anything in media/gmp-clearkey/0.1/ because those files
# use their own RefPtr, defined in their own RefCounted.h.
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
grep -v 'mfbt/RefPtr.h' | \
grep -v 'mfbt/nsRefPtr.h' | \
grep -v 'mfbt/RefCounted.h' | \
grep -v 'media/gmp-clearkey/0.1/' | \
xargs perl -p -i -e '
s/mozilla::RefPtr/nsRefPtr/g; # handle declarations in headers
s/\bRefPtr</nsRefPtr</g; # handle local variables in functions
s#mozilla/RefPtr.h#mozilla/nsRefPtr.h#; # handle #includes
s#mfbt/RefPtr.h#mfbt/nsRefPtr.h#; # handle strange #includes
'
# |using mozilla::RefPtr;| is OK; |using nsRefPtr;| is invalid syntax.
find . -name '*.cpp' -o -name '*.mm' | xargs sed -i -e '/using nsRefPtr/d'
# RefPtr.h used |byRef| for dealing with COM-style outparams.
# nsRefPtr.h uses |getter_AddRefs|.
# Fixup that mismatch.
find . -name '*.cpp' -o -name '*.h'| \
xargs perl -p -i -e 's/byRef/getter_AddRefs/g'
It's a little more convenient than checking Count(), and also gives
nsTHashtable the same interface as nsTArray (for this operation, at
least), which seems worthwhile.
|getReportsForThisProcess| differs from |getReports| in that it is limited to current process and is synchronous. When asynchronous memory reporters are added the function will no longer be able tobe synchronous. There isn't much utility in only measuring the current process, so we can remove the function and switch existing users to |getReports|.
The calculation of |explicit| relies on the synchronous |getReportsForThisProcess|, once we have asynchronous reporters this will no longer work. As it is currently referenced in the about::memory tests we can just remove it.
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
Having a template parameter conflict with a global name is terribly
inconvenient, so let's try to avoid that by renaming the 'RefPtr'
template parameter to something else.
Leave a typedef for compatibility. nsVariant will be defined as a
separate class in the next patch.
Also, remove an obsolete comment and fix some whitespace.
|getReportsForThisProcess| differs from |getReports| in that it is limited to current process and is synchronous. When asynchronous memory reporters are added the function will no longer be able tobe synchronous. There isn't much utility in only measuring the current process, so we can remove the function and switch existing users to |getReports|.
The calculation of |explicit| relies on the synchronous |getReportsForThisProcess|, once we have asynchronous reporters this will no longer work. As it is currently referenced in the about::memory tests we can just remove it.
This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
--HG--
extra : source : 6bf72b4eaa92b13d42b547d8aeee677489a4d3e2
Using forget() to extract mMessage from MessageElement ends up going
from nsCOMPtr<T> to already_AddRefed<T> to nsCOMPtr<T>. For the second
step, the compiler can't tell that the already_AddRefed<T> came from a
canonical nsCOMPtr, so it calls Assert_NoQueryNeeded() in debug
builds. This in turn causes a QI, which does an AddRef. That is bad
because we're not on the main thread, and mMessage is
main-thread-only, so we get an assertion.
This patch works around that by using swap directly between two
nsCOMPtr<>, which avoids the Assert_NoQueryNeeded().
I called the method "swapMessage" rather than "swap" to emphasize that
we are not swapping the whole MessageElement, but just one part of
it. I find the existing forget() name to be confusing.
We don't need to reinterpret_cast when casting from void*, and we don't
need to reinterpret_cast when we're casting up and down a class
hierarchy. static_cast takes care of those cases just fine, and doesn't
scare the reader into thinking that nsTHashtable is doing something
unusual.
This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
--HG--
extra : source : 47cd2c22bafc8d4bb1c7e1dce3b45517aaec199f
This changeset replaces all of the
// char16_t[]
optional bytes someProperty = 1;
one- and two-byte string properties in the CoreDump.proto protobuf definition
file with:
oneof {
// char16_t[]
bytes someProperty = 1;
uint64 somePropertyRef = 2;
}
The first time the N^th unique string is serialized, then someProperty is used
and the full string is serialized in the protobuf message. All following times
that string is serialized, somePropertyRef is used and its value is N.
Among the other things, this also changes JS::ubi::Edge::name from a raw pointer
with commented rules about who does or doesn't own and should and shouldn't free
the raw pointer to a UniquePtr that enforces those rules rather than relying on
developers reading and obeying the rules in the comments.
This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
--HG--
extra : source : 3dbd000739dc0ea214a2292e3983469e41e99686
This moves the app-shipped system add-ons into <appdir>/features. I've created
a new directory provider location for this since it allows us to override the
location without allowing external apps to do so as would be the case with
prefs.
--HG--
extra : commitid : 9lzIzbjvCpK
extra : rebase_source : 1f1f319eac2142ffbe6714289e6fb4e40cfd6088
xptcstubs_arm mostly works on iOS but Apple's assembler is ridiculous so
the inline assembly for the SharedStub and the stub methods needs judicious
preprocessor use.
--HG--
extra : commitid : ChAcktTzVX0
extra : rebase_source : 11fbaa4940fd9aaeba51e2477d4c8b1a7851791e
We want to ensure that nsThread's use of nsEventQueue uses locking done
in nsThread instead of nsEventQueue, for efficiency's sake: we only need
to lock once in nsThread, rather than the current situation of locking
in nsThread and additionally in nsEventQueue. With the current
structure of nsEventQueue, that would mean that nsThread should be using
a Monitor internally, rather than a Mutex.
Which would be well and good, except that DOM workers use nsThread's
mutex to protect their own, internal CondVar. Switching nsThread to use
a Monitor would mean that either:
- DOM workers drop their internal CondVar in favor of nsThread's
Monitor-owned CondVar. This change seems unlikely to work out well,
because now the Monitor-owned CondVar is performing double duty:
tracking availability of events in nsThread's event queue and
additionally whatever DOM workers were using a CondVar for. Having a
single CondVar track two things in such a fashion is for Experts Only.
- DOM workers grow their own Mutex to protect their own CondVar. Adding
a mutex like this would change locking in subtle ways and seems
unlikely to lead to success.
Using a Monitor in nsThread is therefore untenable, and we would like to
retain the current Mutex that lives in nsThread. Therefore, we need to
have nsEventQueue manage its own condition variable and push the
required (Mutex) locking to the client of nsEventQueue. This scheme
also seems more fitting: external clients merely need synchronized
access to the event queue; the details of managing notifications about
events in the event queue should be left up to the event queue itself.
Doing so also forces us to merge nsEventQueueBase and nsEventQueue:
there's no way to have nsEventQueueBase require an externally-defined
Mutex and then have nsEventQueue subclass nsEventQueueBase and provide
its own Mutex to the superclass. C++ initialization rules (and the way
things like CondVar are constructed) simply forbid it. But that's OK,
because we want a world where nsEventQueue is externally locked anyway,
so there's no reason to have separate classes here.
One casualty of this work is removing ChaosMode support from
nsEventQueue. nsEventQueue had support to delay placing events into the
queue, theoretically giving other threads the chance to put events there
first. Unfortunately, since the thread would have been holding a lock
(as is evident from the MutexAutoLock& parameter required), sleeping in
PutEvent accomplishes nothing but delaying the thread from getting
useful work done. We should support this, but it's complicated to
figure out how to reasonably support this right now.
A wrinkle in this overall pleasant refactoring is that nsThreadPool's
threads wait for limited amounts of time for new events to be placed in
the event queue, so that they can shut themselves down if no new events
are appearing. Setting limits on the number of threads also needs to be
able to wake up all threads, so threads can shut themselves down if
necessary.
Unfortunately, with the transition to nsEventQueue managing its own
condition variable, there's no way for nsThreadPool to perform these
functions, since there's no Monitor to wait on. Therefore, we add a
private API for accessing the condition variable and performing the
tasks nsThreadPool needs.
Prior to all the previous patches, placing items in an nsThread's event
queue required three lock/unlock pairs: one for nsThread's Mutex, one to
enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's
ReentrantMonitor. The upshot of all this work is that we now only
require one lock/unlock pair in nsThread itself, as things should be.
Like the previous patch, this patch is a no-op change in terms of
functionality. It does, however, pave part of the way for forcing
clients of nsEventQueue to provide their own locking.
This patch is a no-op in terms of functionality. It ensures that we're
always holding nsThread's mutex when we touch mEvents, as dictated by
the comments. Putting this addition into its own patch will help make
the change to having nsEventQueue by guarded by a Mutex, rather than a
Monitor, somewhat clearer.
This is another case of an access to mEvents not being protected by
mLock. Future patches will make this locking requirement explicit in
nsChainedEventQueue, so we won't have problems like this. (Since
nsEventQueue has its own locking at this point, this omission didn't
matter much, but the omission will most certainly matter later.)
GetEvent was only called from one place, so it wasn't terribly useful as
an abstraction. It also broke the invariant that we protect accesses to
mEvents with mLock, as documented in nsThread.h. While upcoming patches
could have just updated GetEvent to do the necessary locking on its own,
it seemed just as easy to make the locking requirements at the callsite,
as will be done for other accesses to mEvents.
nsEventQueue's monitor does not require re-entrancy now that the monitor
is not externally visible. Since ReentrantMonitors require two separate
mutex lock/unlock pairs (one on entry, and one on exit), this cuts the
amount of locking nsEventQueue's methods do by half.
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.
The breakpad dependency in ThreadStackHelper is preventing us from
upgrading our in-tree copy to a newer version (bug 1069556). This patch
gets rid of that dependency. This makes native stack frames not work
for BHR, but because of the ftp.m.o decommissioning, native
symbolication was already broken and naive stack frames already don't
work, so we don't really lose anything from this patch.
Eventually we want to make ThreadStackHelper use other means of
unwinding, such as LUL for Linux
I added | #if 0 | around the code to fill the thread context, but left
the code in because I think we'll evenually want to reuse some of that
code.
This makes the order of |aDelay| and |aType| match those of the InitWith*()
functions.
I've made this change because the inconsistency tripped me up during the
development of part 4.
--HG--
extra : rebase_source : 7d49f3f643e76955ea3de57e0954deb22cda3ddf
There are many sub-classes of nsExpirationTracker. In order to distinguish them
nicely in the logging of timer firings, it's necessary to manually name each
one. (This wouldn't be necessary if there was a way to stringify template
parameters, but there isn't.)
--HG--
extra : rebase_source : 89b99e9dbb2a806bd21145d04a5e023794643b61
This is similar to the solution adopted for bug 1190985, a race in
netwerk's DebugMutexAutoLock. A relaxed atomic tells tools like TSan
that we're OK with this variable being touched from multiple threads.
That it's only set from within a locked mutex should ensure whatever
memory barriers we need are executed so all threads have a consistent
view of what value it contains.
Getting rid of another |volatile| usage in the codebase is just a bonus.
nsEventQueue's HasPending event is defined to simply:
return GetEvent(false, nullptr);
So we can substitute HasPendingEvent for this particular GetEvent call
to make the code clearer.
Its only purpose is to disable PGO. Where that was not already explicitly done,
or irrelevant (because the directory only contains python), I disabled it in
moz.build.
We're already holding a reference to the Runner prior to dispatching it
to the thread pool; we can pass that reference in rather than requiring
the thread pool to take a new reference to it.
There's no reason to wake up all the threads in a thread pool when one
item gets placed in the queue. Waking up one will serve the same
purpose and is significantly more efficient for thread pools with large
numbers of threads.
There's no reason nsThreadPool needs to use a reentrant monitor for
locking its event queue. Having it use a non-reentrant one should be
slightly more efficient, both in the general operation of the monitor,
and that we're not performing redundant locking in methods like
nsThreadPool::Run. This change also eliminates the only usage of
nsEventQueue::GetReentrantMonitor.
Clients of nsEventQueue don't always need fully reentrant monitors.
Let's account for that by having a base class templated on the monitor
type. This change also opens up the possibility of having the monitor
for the event queue not owned by the event queue itself, but by the
client class, which makes a lot more sense than the current design.
The comment here suggests that we might AddRef/Release, but we really do
no such thing. Let's deal with the transfer of ownership directly,
rather than going through nsCOMPtr. This change makes the code slightly
smaller, and it also makes later refactorings to pull the lock out of
this function easier to do, since we don't have to consider how to hold
the lock within the lifetime of the nsCOMPtr temporary.
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
This gives zero when jemalloc is enabled and non-zero when jemalloc is disabled
(e.g. I got 83 MiB at start-up, which sounds plausible).
--HG--
extra : rebase_source : f39a15472d48643f57a77f1df03e4a29543d0867
This is motivated by three separate but related problems:
1. Our concept of recursion depth is broken for things that run from AfterProcessNextEvent observers (e.g. Promises). We decrement the recursionDepth counter before firing observers, so a Promise callback running at the lowest event loop depth has a recursion depth of 0 (whereas a regular nsIRunnable would be 1). This is a problem because it's impossible to distinguish a Promise running after a sync XHR's onreadystatechange handler from a top-level event (since the former runs with depth 2 - 1 = 1, and the latter runs with just 1).
2. The nsIThreadObserver mechanism that is used by a lot of code to run "after" the current event is a poor fit for anything that runs script. First, the order the observers fire in is the order they were added, not anything fixed by spec. Additionally, running script can cause the event loop to spin, which is a big source of pain here (bholley has some nasty bug caused by this).
3. We run Promises from different points in the code for workers and main thread. The latter runs from XPConnect's nsIThreadObserver callbacks, while the former runs from a hardcoded call to run Promises in the worker event loop. What workers do is particularly problematic because it means we can't get the right recursion depth no matter what we do to nsThread.
The solve this, this patch does the following:
1. Consolidate some handling of microtasks and all handling of stable state from appshell and WorkerPrivate into CycleCollectedJSRuntime.
2. Make the recursionDepth counter only available to CycleCollectedJSRuntime (and its consumers) and remove it from the nsIThreadInternal and nsIThreadObserver APIs.
3. Adjust the recursionDepth counter so that microtasks run with the recursionDepth of the task they are associated with.
4. Introduce the concept of metastable state to replace appshell's RunBeforeNextEvent. Metastable state is reached after every microtask or task is completed. This provides the semantics that bent and I want for IndexedDB, where transactions autocommit at the end of a microtask and do not "spill" from one microtask into a subsequent microtask. This differs from appshell's RunBeforeNextEvent in two ways:
a) It fires between microtasks, which was the motivation for starting this.
b) It no longer ensures that we're at the same event loop depth in the native event queue. bent decided we don't care about this.
5. Reorder stable state to happen after microtasks such as Promises, per HTML. Right now we call the regular thread observers, including appshell, before the main thread observer (XPConnect), so stable state tasks happen before microtasks.
Phil Ringnalda
Jeff Walden
Chris Peterson
Wes Kocher
Alessio Placitelli
Carsten "Tomcat" Book
Honza Bambas
sajitk
Ben Kelly
ffxbld
Makoto Kato
Birunthan Mohanathas
Nathan Froyd
Tooru Fujisawa
Cameron McCormack
Eric Rahm
Ehsan Akhgari
Cervantes Yu
Shih-Chiang Chien
Mike Hommey
Nigel Babu
Aryeh Gregor
Hiroyuki Ikezoe
Xidorn Quan
Boris Zbarsky
Andrew McCreight
Shu-yu Guo
Nicholas Nethercote
Jean-Yves Avenard
Nick Fitzgerald
Jason Orendorff
Dave Townsend
Ted Mielczarek
James Cheng
Daniel Holbert
Peter Van der Beken
Jim Chen
Kan-Ru Chen
Kyle Huey
Michael Layzell
Ms2ger
Nikhil Marathe
Milan Sreckovic
Milan Sreckovic
Randell Jesup
Miko Mynttinen
Andrew McCreight
Florian Quèze
David Major
Terrence Cole
Alphan Chen
Seth Fowler
Bobby Holley
Chris Manchester
Arnaud Bienner
Mike Conley
Francois Marier
Alfredo Yang