PLDHashTable's entry store has two types of unoccupied entries: free
entries and removed entries. The search of a chain of entries
(determined by the hash value) in the entry store to search for an entry
can stop at free entries, but it continues across removed entries,
because removed entries are entries that may have been skipped over when
we were adding the value we're searching for to the hash, but have since
been removed. For live entries, we also maintain this distinction by
using one bit of storage for a collision flag, which notes that if the
hashtable entry is removed, its place in the entry store must become a
removed entry rather than a free entry.
When we add a new entry to the table, Add's semantics require that we
return an existing entry if there is one, and only create a new entry if
no existing entry exists. (Bug 1352198 suggests the possibility of a
faster alternative Add API where the caller guarantees that the key is
not already in the hashtable.) When we search for the existing entry,
we must thus continue the search across removed entries, even though we
record the first removed entry found to return if the search for an
existing entry fails.
The existing code adds the collision flag through the entire table
search during an Add. This patch changes that behavior so that we only
add the collision flag prior to finding the first removed entry. Adding
it after we find the first removed entry is unnecessary, since we are
not making that entry part of a path to a new entry. If it is part of a
path to an existing entry, it will already have the collision flag set.
This patch effectively puts an if (!firstRemoved) around the else branch
of the if (MOZ_UNLIKELY(EntryIsRemoved(entry))), and then refactors that
condition outwards since it is now around the contents of both the if
and else branches.
MozReview-Commit-ID: CsXnMYttHVy
--HG--
extra : transplant_source : W4%B8%BA%D5p%102%1B%8D%83%23%E0s%B3%B0f%0D%05%AE
We need this because the stored values in the hash table may themselves
be main-thread only objects, and destroying them off the main thread
will cause crashes.
PLDHashTable takes the result of the hash function and multiplies it by
kGoldenRatio to ensure that it has a good distribution of bits across
the 32-bit hash value, and then zeroes out the low bit so that it can be
used for the collision flag. This result is called hash0. From hash0
it computes two different numbers used to find entries in the table
storage: hash1 is used to find an initial position in the table to
begin searching for an entry; hash2 is then used to repeatedly offset
that position (mod the size of the table) to build a chain of positions
to search.
In a table with capacity 2^c entries, hash1 is simply the upper c bits
of hash0. This patch does not change this.
Prior to this patch, hash2 was the c bits below hash1, padded at the low
end with zeroes when c > 16. (Note that bug 927705, changeset
1a02bec165e16f370cace3da21bb2b377a0a7242, increased the maximum capacity
from 2^23 to 2^26 since 2^23 was sometimes insufficient!) This manner
of computing hash2 is problematic because it increases the risk of long
chains for very large tables, since there is less variation in the hash2
result due to the zero padding.
So this patch changes the hash2 computation by using the low bits of
hash0 instead of shifting it around, thus avoiding 0 bits in parts of
the hash2 value that are significant.
Note that this changes what hash2 is in all cases except when the table
capacity is exactly 2^16, so it does change our hashing characteristics.
For tables with capacity less than 2^16, it should be using a different
second hash, but with the same amount of random-ish data. For tables
with capacity greater than 2^16, it should be using more random-ish
data.
MozReview-Commit-ID: JvnxAMBY711
--HG--
extra : transplant_source : %8A%25%FB%E3H%B8_%F1G%F6%3E%0B%29%DF%20%FF%D8%E1%AEw
PLDHashTable's entry store has two types of unoccupied entries: free
entries and removed entries. The search of a chain of entries
(determined by the hash value) in the entry store to search for an entry
can stop at free entries, but it continues across removed entries,
because removed entries are entries that may have been skipped over when
we were adding the value we're searching for to the hash, but have since
been removed. For live entries, we also maintain this distinction by
using one bit of storage for a collision flag, which notes that if the
hashtable entry is removed, its place in the entry store must become a
removed entry rather than a free entry.
When we add a new entry to the table, Add's semantics require that we
return an existing entry if there is one, and only create a new entry if
no existing entry exists. (Bug 1352198 suggests the possibility of a
faster alternative Add API where the caller guarantees that the key is
not already in the hashtable.) When we search for the existing entry,
we must thus continue the search across removed entries, even though we
record the first removed entry found to return if the search for an
existing entry fails.
The existing code adds the collision flag through the entire table
search during an Add. This patch changes that behavior so that we only
add the collision flag prior to finding the first removed entry. Adding
it after we find the first removed entry is unnecessary, since we are
not making that entry part of a path to a new entry. If it is part of a
path to an existing entry, it will already have the collision flag set.
This patch effectively puts an if (!firstRemoved) around the else branch
of the if (MOZ_UNLIKELY(EntryIsRemoved(entry))), and then refactors that
condition outwards since it is now around the contents of both the if
and else branches.
MozReview-Commit-ID: CsXnMYttHVy
--HG--
extra : transplant_source : 0T%B0%FA%C0%85v%8B%16%E7%81%03p%F5K%97%B1%9E%92%27
This adds an arena allocator that can be used as a drop-in replacement for
NSPR's PLArena. Example usage for defining an 8-byte aligned allocator that
uses a 4K arena size:
mozilla::ArenaAllocator<4096,8> a;
void* memory = a.Allocate(200);
This adds release bounds checking to ReplaceElementsAt, InsertElementAt, and
InsertElementsAt to make sure the insertion point is within the current array
bounds.
MozReview-Commit-ID: 1pFr8LuOROI
Handling potential nsDeque size changes means a bit of extra work.
But if the nsDeque is const, we can assume that it shouldn't get modified, so
we can provide a more optimized iterator that doesn't need to handle size
changes.
Optimizing a range-for loop in which the deque is not modified, can be done
by writing: `for (void* item : const_cast<const nsDeque&>(deque)) {...}`
MozReview-Commit-ID: AFupjoTsoH3
--HG--
extra : rebase_source : a71b09c9cb73787ce686c7c762f92ef0c208e76a
Note that iterators stay at the same index if the deque size changes
(including end-iterators staying at the end).
This means that after front operations, iterators will effectively point at
different elements! (Possibly skipping or re-visiting some.)
But this is consistent with ForEach and hand-crafted index-based for loops.
MozReview-Commit-ID: 5IvazJR68dG
--HG--
extra : rebase_source : c574fd2d2642d784482698c0fc861269200d1059
It's now possible to write:
for (void* item : deque) { ... }
MozReview-Commit-ID: FLoczCZd77y
--HG--
extra : rebase_source : 237293e94b478beb2bf352c1179d42c289dda145
This could have been done more simply, but the small amount of
refactoring that takes place in this comment enables better error
messages in the case where something does go wrong.
nsContentUtils::IsPatternMatching is the most common by far, but the
other two are generic locations that may cover a number of issues.
MozReview-Commit-ID: Kli39btsqdd
--HG--
extra : rebase_source : 1a7eda2a711f079978b54012d9c7466bbd6de36f
This marks the idl classes as deprecated, removes an unnecessary include that
was triggering deprecation warnings and wraps a necessary include in
XPCOMInit.cpp that is used for registering the component in deprecation
disabling pragmas.
MozReview-Commit-ID: BbNU5q8O4Q4
This adds an intermediate interface, nsIArrayExtensions, that inherits from
nsIArray. This is necessary as nsISupportsArray implements nsIArray as well
so the methods could not just be addded to nsIArray. nsIMutableArray inherits
from nsIArrayExtensions and so any interface that works with an nsIMutableArray
can be updated to return an nsIArrayExtensions.
This will allow interfaces that currently return an nsISupportsArray to instead
return an nsIArrayExtensions and internally work with an nsIMutableArray.
Consumers of these functions will continue to be able to use
nsISupportsArray-like iteration even though they're now working with an
nsIArray.
MozReview-Commit-ID: 9uRjsJbg9Jp
This makes nsSupportsArray implement the |nsIArray| interface. This will allow
us to replace references to nsISupportsArray as a param in our gecko interfaces
with nsIArray instead.
The goal is to remove this adapter (and nsISupportsArray) after a full release
cycle.
MozReview-Commit-ID: If7RiO5muIk
This removes the scriptable method |Compact| which is unused in
our codebase and turns up no references in the plugins repo.
MozReview-Commit-ID: 5sJtO5COJpB
This removes the scriptable method |GetLastIndexOf| which is unused in
our codebase and turns up no references in the plugins repo. This allows to
remove the non-scriptable |LastIndexOf|.
MozReview-Commit-ID: 54Ux7yZMh4F
This removes the scriptable method |GetIndexOfStartingAt| which is unused in
our codebase and turns up no references in the plugins repo. This allows to
remove the non-scriptable |IndexOfStartingAt| which is folded into |IndexOf|.
MozReview-Commit-ID: 2ADz5mLIvMU
|DeleteLastElement| is scriptable, but a search of our add-on repo turned up
no hits and there were no references in gecko code. This also allows us to
remove the non-scriptable |RemoveLastElement| which was only called by
|DeleteLastElement|.
MozReview-Commit-ID: 20FXBrosacA
This removes the scriptable method |GetIndexOfStartingAt| which is unused in
our codebase and turns up no references in the plugins repo. This allows to
remove the non-scriptable |IndexOfStartingAt| which is folded into |IndexOf|.
MozReview-Commit-ID: 2ADz5mLIvMU
|DeleteLastElement| is scriptable, but a search of our add-on repo turned up
no hits and there were no references in gecko code. This also allows us to
remove the non-scriptable |RemoveLastElement| which was only called by
|DeleteLastElement|.
MozReview-Commit-ID: 20FXBrosacA
This adds size checks when growing the nsISupportsArray. It also removes
|InsertElementsAt| and |AppendElements| which are unused notxpcom interfaces
that would need similar modifications.
MozReview-Commit-ID: ET32q0OCrLU
This patch removes checking of all the callback calls in memory reporter
CollectReport() functions, because it's not useful.
The patch also does some associated clean-up.
- Replaces some uses of nsIMemoryReporterCallback with the preferred
nsIHandleReportCallback typedef.
- Replaces aCallback/aCb/aClosure with aHandleRepor/aData for CollectReports()
parameter names, for consistency.
- Adds MOZ_MUST_USE/[must_use] in a few places in nsIMemoryReporter.idl.
- Uses the MOZ_COLLECT_REPORT macro in all suitable places.
Overall the patch reduces code size by ~300 lines and reduces the size of
libxul by about 37 KiB on my Linux64 builds.
--HG--
extra : rebase_source : e94323614bd10463a0c5134a7276238a7ca1cf23
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Slightly less than half (93 / 210) of the NS_METHOD instances in the codebase
are because of the use of NS_CALLBACK in
nsI{Input,Output,UnicharInput},Stream.idl. The use of __stdcall on Win32 isn't
important for these callbacks because they are only used as arguments to
[noscript] methods.
This patch converts them to vanilla |nsresult| functions. It increases the size
of xul.dll by about ~600 bytes, which is about 0.001%.
--HG--
extra : rebase_source : c15d85298e0975fd030cd8f8f8e54501f453959b
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Michael Layzell
Petr Sumbera
Florian Queze
Carsten "Tomcat" Book
Eric Rahm
Daniel Holbert
Bevis Tseng
L. David Baron
Nathan Froyd
Olli Pettay
Henri Sivonen
Xidorn Quan
Andrew McCreight
Wes Kocher
Ehsan Akhgari
Honza Bambas
Emanuel Hoogeveen
Boris Zbarsky
Gerald Squelart
Jorg K
Julian Seward
Benjamin Smedberg
Sebastian Hengst
Thomas Wisniewski
David Anderson
Nicholas Nethercote
Kan-Ru Chen
Igor
Matthew Wein
Tom Tromey
Chris Peterson
Ralph Giles
Jarda Snajdr