Note that enumfunc_pentries and persistent_userstruct are unused, and so could
be removed.
--HG--
extra : rebase_source : 57ae41aa2e7d514dc8f3f3d79d3d1946a407c4ac
This is a particularly nice example of how iterators can be so much nicer than
Enumerate()-style functions:
1 file changed, 4 insertions(+), 33 deletions(-)
--HG--
extra : rebase_source : 757f75b90cb4c624143c236f9743edf158f72d66
nsBaseHashtable has both EnumerateRead() and Enumerate(). A comment claims that
the latter locks the table, but this is false, so I removed the comment. Other
than that the only notable difference between them is that they have slightly
different types for dealing with values (|UserDataType| vs |DataType&|) so I've
implemented both GetUserData() and GetData(), allowing either type to be used.
--HG--
extra : rebase_source : 9d61cc8f4c14082c9f1939ff3ced2b697e043f42
Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into believing it's the
root of their problems.
The only way left to force the slice allocator to use "system" malloc (in
practice, jemalloc) is to set the G_SLICE environment variable to
always-malloc, and that needs to happen before glib is loaded.
Fortunately, the firefox and plugin-container executables don't depend on
glib. Unfortunately, webapprt does, so the problem remains for web apps
running through it. xpcshell and other executables that depend on libxul
directly (as opposed to loading it dynamically) are not covered either.
Adding isMainProcessScriptable() into the middle of nsIInterfaceInfo
caused problems with some binary addons that relied on the ordering of
the methods in nsIInterfaceInfo. In an attempt to placate those addons,
move isMainProcessScriptable() to the end of the vtable. This change is
a no-op for normal libxul usage.
The original motivation for the Iterator/RemovingIterator split was that
PLDHashTable Checker class would treat them differently. But that didn't end up
happening (see bug 1131308). So this patch merges them. This is a small code
size win now but it will become bigger when I add iterators to nsTHashTable and
nsBaseHashtable.
The only complication is that PLDHashTable::Iter() is now non-const, which is
a problem if you use it in a const method. So I added PLDHashTable::ConstIter()
which is used in just two places. It's a bit of a hack -- effectively a
const_cast -- but I don't think it's too bad.
The switch to unsigned integer constants (e.g. "0u") are necessary to avoid
compiler warnings about signed/unsigned comparisons.
--HG--
rename : xpcom/tests/TestPLDHash.cpp => xpcom/tests/gtest/TestPLDHash.cpp
extra : rebase_source : e159d6444581fd0063c5274419ac2126a94607bf
- Its move constructor was moving |aOther.mTable| instead of |aOther|. This
meant that |aOther| wasn't being zeroed out appropriately.
- test_pldhash_RemovingIterator() was testing Iterator's move constructor
instead of RemovingIterator's move constructor, due to a copy/paste
mistake.
--HG--
extra : rebase_source : 1f4880893875218ddb155c76d329e84d884c0432
Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into believing it's the
root of their problems.
The only way left to force the slice allocator to use "system" malloc (in
practice, jemalloc) is to set the G_SLICE environment variable to
always-malloc, and that needs to happen before glib is loaded.
Fortunately, the firefox and plugin-container executables don't depend on
glib. Unfortunately, webapprt does, so the problem remains for web apps
running through it. xpcshell and other executables that depend on libxul
directly (as opposed to loading it dynamically) are not covered either.
Constructing kComponentsInterfaceShimMap required a static constructor
on some compilers, due to a non-constexpr constructor and the necessity
of copying non-constexpr things like nsIID. This static constructor is
large (several kilobytes of object code on x86-64) and completely
unnecessary.
To fix this, let's add a constexpr (well, MOZ_CONSTEXPR) constructor to
ComponentsInterfaceShimEntry. This change alone doesn't completely
solve our problem, because the nsIID member still needs to be copied.
But doing that copying is silly: we only use the IID for constructing a
ShimInterfaceInfo in ShimInterfaceInfo::MaybeConstruct, and the
ShimInterfaceInfo constructor takes a const reference. So let's store a
const reference in ComponentsInterfaceShimEntry, too, and make that
structure significantly smaller in the process.
PostTimerEvent is only called by the timer thread, which is already able
to access private members of nsTimerImpl; there's no reason for
PostTimerEvent to be public.
GetTracedTask() is only called from nsTimerImpl itself, so it doesn't
need to be public. GetTLSTraceInfo() is called from the timer thread,
which has access to our private members already.
This patch factors out the existing capacity calculation code in HashShift()
into a new function called BestCapacity(), and then reuses it for
post-enumeration shrinking.
BestCapacity() computes capacity with |CeilingLog2(ceil(length * 4 / 3))|,
which ensures a minimum capacity while respecting the "max 75% full" and
"capacity is a power of two" constraints. In contrast, the old post-enumeration
shrink calculation was |CeilingLog2(length + length/2)|, which gives higher
results in some cases. (Both calculations also ensured the capacity wasn't too
small.) E.g. if length is 48, the former calculation will give 64, while the
latter will give 128.
Therefore, post-enumeration shrinking will no longer give a
larger-than-necessary capacity some cases. This feels like the right thing to
do in isolation, and making it consistent with HashShift() -- used during table
construction -- is also good.
--HG--
extra : rebase_source : 55e982b601c345d10da7abd03a13aec3f5b61598
This change splits PLDHashTable::Iterator::NextEntry() into two separate
functions, which allow you to get the current element and advance the iterator
separately, which means you can use a for-loop to iterate instead of a
while-loop.
As part of this change, the internals of PLDHashTable::Iterator were
significantly changed and simplified (and modelled after js::HashTable's
equivalent code). It's no longer duplicating code from PL_DHashTableEnumerator.
The chaos mode code was a casualty of this, but given how unreliable that code
has proven to be (see bug 1173212, bug 1174046) this is for the best. (We can
reimplement chaos mode once PLDHashTable::Iterator is back on more solid
footing again, if we think it's important.)
All these changes will make it much easier to add an alternative Iterator that
removes elements, which was turning out to be difficult with the prior code.
In order to make the for-loop header usually fit on a single line, I
deliberately renamed a bunch of things to have shorter names.
In summary, you used to write this:
PLDHashTable::Iterator iter(&table);
while (iter.HasMoreEntries()) {
auto entry = static_cast<FooEntry*>(iter.NextEntry());
// ... do stuff with |entry| ...
}
// iter's scope extends beyond here
and now you write this:
for (auto iter = table.Iter(); !iter.Done(); iter.Next()) {
auto entry = static_cast<FooEntry*>(iter.Get());
// ... do stuff with |entry| ...
}
// iter's scope doesn't reach here
--HG--
extra : rebase_source : fa5cac2fc50b1ab7624030bced4763131280f4d8
If you use PLDHashTable::Iterator in chaos mode with a table with zero
capacity, a |% 0| operation takes place in randomUint32LessThan. This change
avoids that.
--HG--
extra : rebase_source : 85f2affb57c2402f40f3d117434b8300e7f204b7
This change reimplements nsTHashtable::Clear() using PLDHashable::Clear(). This
changes its semantics slightly -- the old version would clear the table but
leave its capacity unchanged. The new version will adjust the capacity
to the default, though the entry storage will only be re-allocated when the
first new element is added.
The old code attempted to deal with any OOMs during this enumeration --
OOMs are possible because it's growing an nsCOMArray -- but failed to do so
correctly.
- It didn't check the return value of AppendObject().
- It did check that EntryCount() matched the return value of
PL_DHashTableEnumerate(), but that's always (and vacuously) true.
The new code just returns NS_ERROR_OUT_OF_MEMORY if AppendObject() fails; this
is trivial now that it uses an iterator and doesn't have to call out to another
function.
Iterator::NextEntry() miscomputes |entryLimit|. This doesn't matter in
non-chaos mode because we'll always find a live entry before hitting that
limit. But it does matter in chaos mode because it means we don't wrap around
when we should.
It's clear how this mistake was made -- the code from Enumerate() was copied.
In Enumerate() |mEntryStore| and |entryAddr| are the same when |entryLimit| is
computed, so you can use them interchangeably. But in NextEntry() |mEntryAddr|
will have moved past |mEntryStore|, so you have to use |mEntryStore|. I changed
both functions in the same way to keep the correspondence between them obvious.
--HG--
extra : rebase_source : f27558b3179be394526d1c3f82ffbae0fb58b2b9
This patch makes it so that while the cycle collector is running methods are called
on the concrete implementation nsCycleCollectorLogger, rather than the interface
nsICycleCollectorListener. This makes explicit the requirement that we have to be
very careful about what we call during the cycle collector, and should make it
possible for the GC rooting static analysis to understand what is happening.
The UUID of nsICycleCollectorHandler was changed to appease the UUID commit hook.
Make it harder for users to accidentally reintroduce usage of the PR_LOG macros
when using 'mozilla/Logging.h'. This can still be worked around by directly
including 'prlog.h' (and not 'mozilla/Logging.h') if absolutely necessary.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This adds the mozilla::LogLevel enum class. Additionaly a log_test function is
added to use rather than a macro, this allows us to enforce only
mozilla::LogLevel is passed into the function.
|mOps| is always non-null now, and there's no longer any distinction between
and uninitialized and initialized table. Yay.
--HG--
extra : rebase_source : 3d1fb72aee4dd21ff20db0ff3166d4e932ade897
Make it harder for users to accidentally reintroduce usage of the PR_LOG macros
when using 'mozilla/Logging.h'. This can still be worked around by directly
including 'prlog.h' (and not 'mozilla/Logging.h') if absolutely necessary.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This adds the mozilla::LogLevel enum class. Additionaly a log_test function is
added to use rather than a macro, this allows us to enforce only
mozilla::LogLevel is passed into the function.
Make it harder for users to accidentally reintroduce usage of the PR_LOG macros
when using 'mozilla/Logging.h'. This can still be worked around by directly
including 'prlog.h' (and not 'mozilla/Logging.h') if absolutely necessary.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This adds the mozilla::LogLevel enum class. Additionaly a log_test function is
added to use rather than a macro, this allows us to enforce only
mozilla::LogLevel is passed into the function.
This helps upcoming changes, and relieves backends from path resolution.
This has the side effect of chaning the order of some unified sources,
which consequently breaks nsTextFormatter because it declares snprintf
methods after nsStringAPI #defines it.
The added static_casts will be removed when PLDHashTable and PLDHashTable2 are
merged.
--HG--
extra : rebase_source : 49dacef8a86adc088610449b6bd2ef9345af5a84
CLOSED TREE
Backed out changeset 12ce98475c6e (bug 1119980)
Backed out changeset bdb8d05f8870 (bug 1119980)
Backed out changeset a68a18840492 (bug 1119980)
This patch simplifies nsStaticCaseInsensitiveNameTable greatly by taking
advantage of the following observations.
- |new| is infallible, so |new nsStaticCaseInsensitiveNameTable()| calls don't
need their return value checked.
- nsStaticCaseInsensitiveNameTable::Init() checks if any of the added entries
differ only in case, so the callers of that function don't need to do the
same check.
- nsStaticCaseInsensitiveNameTable::Init() never returns false because
moz_xmalloc() is infallible. (Its callers never check the return value
anyway.) So it can be merged into the constructor. And
~nsStaticCaseInsensitiveNameTable() need not null-check |mNameArray|.
- PLDHashTable now has an initializing constructor and destructor, so these can
be used in nsStaticCaseInsensitiveNameTable, thus avoiding manual
PLD_HashTable{Init,Finish}() calls.
This patch converts easy cases, i.e. where the PL_DHashTableInit() call occurs
in a constructor and the PL_DHashTableFinish() call occurs in a destructor.
--HG--
extra : rebase_source : d8dc450f80ac23b8455141b471cc9ae823e1e384
This is a temporary sub-class of PLDHashTable that will allow PLDHashTable to
be incrementally transitioned from manual initialization/finalization (via
explicit Init()/Fini() calls) to automatic initialization/finalization (via an
initializing constructor and a destructor). Once all PLDHashTable instances are
converted to PLDHashTable2, it can be folded back into PLDHashTable and the "2"
suffix can be dropped.
--HG--
extra : rebase_source : 674e7bd9320dc1db8879f842df05a7d995069e97
The SetOps() call is no longer necessary now that PLDHashTable has a move
constructor.
This change originally landed in one of the patches from bug 1161377, which was
subsequently backed out.
Due to Android startup regressions (bug 1163066) and plugin crashes (bug
1165155).
--HG--
extra : rebase_source : 380f79e67dff4c4eaa2614f286a4d0669666b652
Various parts of the first half of BeginCollection() can start an incremental GC.
This is bad because running the GC and CC at the same time can cause the CC to end
up with pointers to dead JS objects.
To avoid this, we finish any incremental GC in progress in BeginCollection. This
is slow, but hopefully it is rare.
This changes the way nsMemoryReporterManger handles child processes;
instead of using an observer message and trying to keep a count of child
processes expected to answer, it directly iterates a copy of the list
of content processes and explicitly handles children which exit before
their reports start.
Note that GC/CC logs still run at full concurrency, and that no child
reports start until the parent is finished (see bug 1151597) regardless
of concurrency limit.
This changes the way nsMemoryReporterManger handles child processes;
instead of using an observer message and trying to keep a count of child
processes expected to answer, it directly iterates a copy of the list
of content processes and explicitly handles children which exit before
their reports start.
Note that GC/CC logs still run at full concurrency, and that no child
reports start until the parent is finished (see bug 1151597) regardless
of concurrency limit.
This fixes the following problems with PLDHashTable::operator=:
- It doesn't handle self-assigments.
- It leaks the memory used by the assigned-to table.
- It doesn't leave the assigned-from table in a safely destructable state.
--HG--
extra : rebase_source : 433ac3418c00e3bb6d376982e4c679d27e42a377
This patch converts easy cases, i.e. where the PL_DHashTableInit() call occurs
in a constructor and the PL_DHashTableFinish() call occurs in a destructor.
The destructor is "opt-in" -- there's a flag that makes it a no-op unless the
table was initialized with the initializing constructor. This will allow us to
incrementally convert existing tables from manual to automatic
initialization/finalization. This is important because some of the existing
uses are tricky (impossible?) to convert to the automatic style.
They are kept around for the sake of the standalone glue, which is used
for e.g. webapprt, which doesn't have direct access to jemalloc, and thus
still needs a wrapper to go through the xpcom function list and get to
jemalloc from there.
It's no longer needed now that entry storage isn't allocated there. (The other
possible causes of failures in that function are less interesting and simply
crashing is a reasonable thing to do for them.)
This also makes PL_DNewHashTable() infallible, so I removed some
now-unnecessary checks of its result.
--HG--
extra : rebase_source : 4c6ab0c449bc18e8bace8bf036b5bd78d3a2f1c4
mData will get automatically constructed when DataType is a class or
struct with a default constructor, but a number of uses of
nsBaseHashtable use integer or pointer types as DataType. Explicitly
initialize mData so that it looks as though we're fully initializing the
class in such cases.
Also fixes bug 1005154 -- since there's now a method for "end of report",
we might as well call it from ActorDestroy instead of Recv__delete__.
--HG--
extra : rebase_source : 89f467fbc553a1a3a4d9b144fff747fa3447f21b
Coverty complains that we're using sizeof(mData) here instead of
sizeof(*mData). They're equivalent for all the architectures we care about,
but go ahead and tidy up the syntax to silence the static analyzer.
The current name reads to me like a boolean variable, even though it's
actually a counter. Try to make that property more explicit at its uses
by renaming it to something more evocative of counter-ness.
2015-04-24 16:04:50 -04:00
Chih-Kai (Patrick) Wang ext:(%2C%20Cervantes%20Yu%20%3Ccyu%40mozilla.com%3E)
Nicholas Nethercote
Jim Mathies
Randell Jesup
Mike Hommey
Nathan Froyd
Birunthan Mohanathas
Dragana Damjanovic
Robert O'Callahan
Bill McCloskey
Gabriele Svelto
Andrea Marchesini
Fabrice Desré
Juan Gomez
Phil Ringnalda
Hamzata Diallo
Ryan VanderMeulen
Boris Kudryavtsev
William Chen
Jan de Mooij
Wes Kocher
ffxbld
David Major
Chris Peterson
Benoit Girard
Carsten "Tomcat" Book
Tom Tromey
Boris Zbarsky
Andrew McCreight
Shelly Lin
Florian Quèze
Terrence Cole
Ted Mielczarek
Eric Rahm
Nick Fitzgerald
Edwin Flores
Nikhil Marathe
doofgod
Gijs Kruitbosch
Heiher
Honza Bambas
Botond Ballo
Michael Layzell
Randall Barker
Andrew Osmond
Josh Matthews
Yanis Sellami
Cervantes Yu
Philipp Kewisch
Jim Chen
Felix Janda
Bob Owen
Gerald Squelart
Neil Rashbrook
Brian O'Keefe
Ganesh Sahukari
Jed Davis
Ehsan Akhgari
Steve Fink
Benjamin Smedberg
Anton Myagkov
Jean-Yves Avenard
Valentin Gosu
Matt Woodrow
Chih-Kai (Patrick) Wang ext:(%2C%20Cervantes%20Yu%20%3Ccyu%40mozilla.com%3E)
Ginn Chen
Kyle Huey
Brian Hackett