| BitArray.h |
namespace js |
2865 |
| Bitmap.cpp |
|
3131 |
| Bitmap.h |
|
5605 |
| Fifo.h |
|
5206 |
| FixedLengthVector.h |
|
2720 |
| IdValuePair.h |
namespace js |
992 |
| InlineTable.h |
|
17005 |
| LifoAlloc.cpp |
static |
12877 |
| LifoAlloc.h |
|
40238 |
| MemoryProtectionExceptionHandler.cpp |
A class to store the addresses of the regions recognized as protected
by this exception handler. We use a splay tree to store these addresses.
|
29120 |
| MemoryProtectionExceptionHandler.h |
This structure allows you to annotate crashes resulting from unauthorized
access to protected memory in regions of interest, to make them stand out
from other heap corruption crashes.
|
1461 |
| Nestable.h |
(Concrete*) -> bool |
1779 |
| OrderedHashTable.h |
Define two collection templates, js::OrderedHashMap and js::OrderedHashSet.
They are like js::HashMap and js::HashSet except that:
- Iterating over an Ordered hash table visits the entries in the order in
which they were inserted. This means that unlike a HashMap, the behavior
of an OrderedHashMap is deterministic (as long as the HashPolicy methods
are effect-free and consistent); the hashing is a pure performance
optimization.
- Range objects over Ordered tables remain valid even when entries are
added or removed or the table is resized. (However in the case of
removing entries, note the warning on class Range below.)
- The API is a little different, so it's not a drop-in replacement.
In particular, the hash policy is a little different.
Also, the Ordered templates lack the Ptr and AddPtr types.
Hash policies
See the comment about "Hash policy" in HashTable.h for general features that
hash policy classes must provide. Hash policies for OrderedHashMaps and Sets
differ in that the hash() method takes an extra argument:
static js::HashNumber hash(Lookup, const HashCodeScrambler&);
They must additionally provide a distinguished "empty" key value and the
following static member functions:
bool isEmpty(const Key&);
void makeEmpty(Key*);
|
31001 |
| PageProtectingVector.h |
PageProtectingVector is a vector that can only grow or be cleared, restricts
access to memory pages that haven't been used yet, and marks all of its fully
used memory pages as read-only. It can be used to detect heap corruption in
important buffers, since anything that tries to write into its protected
pages will crash. On Nightly and Aurora, these crashes will additionally be
annotated with a moz crash reason using MemoryProtectionExceptionHandler.
PageProtectingVector's protection is limited to full pages. If the front
of its buffer is not aligned on a page boundary, elems preceding the first
page boundary will not be protected. Similarly, the end of the buffer will
not be fully protected unless it is aligned on a page boundary. Altogether,
up to two pages of memory may not be protected.
|
15652 |
| PriorityQueue.h |
Class which represents a heap based priority queue using a vector.
Inserting elements and removing the highest priority one are both O(log n).
Template parameters are the same as for Vector, with the addition that P
must have a static priority(const T&) method which returns higher numbers
for higher priority elements.
|
2998 |
| Sort.h |
Helper function for MergeSort. |
3949 |
| SplayTree.h |
Class which represents a splay tree with nodes allocated from a LifoAlloc.
Splay trees are balanced binary search trees for which search, insert and
remove are all amortized O(log n).
T indicates the type of tree elements, C must have a static
compare(const T&, const T&) method ordering the elements. As for LifoAlloc
objects, T objects stored in the tree will not be explicitly destroyed.
|
8898 |
| TraceableFifo.h |
|
3511 |