Entry storage allocation now occurs on the first lookupForAdd()/put()/putNew().
This removes the need for init() and initialized(), and matches how
PLDHashTable/nsTHashtable work. It also removes the need for init() functions
in a lot of types that are built on top of mozilla::Hash{Map,Set}.
Pros:
- No need for init() calls and subsequent checks.
- No memory allocated for empty tables, which are not that uncommon.
Cons:
- An extra branch in lookup() and lookupForAdd(), but not in put()/putNew(),
because the existing checkOverloaded() can handle it.
Specifics:
- Construction now can take a length parameter.
- init() is removed. Explicit length-setting, when necessary, now occurs in the
constructors.
- initialized() is removed.
- capacity() now returns zero when the entry storage is absent.
- lookupForAdd() is no longer `const`, because it can instantiate the storage,
which requires modifications.
- lookupForAdd() can now return an invalid AddPtr in two cases:
- old: hashing failure (due to OOM in the hasher)
- new: OOM while instantiating entry storage
The existing failure handling paths for the old case work for the new case.
- clear(), finish(), and clearAndShrink() are replaced by clear(), compact(),
and reserve(). The old compactIfUnderloaded() is also removed.
- Capacity computation code is now in its own functions, bestCapacity() and
hashShift(). setTableSizeLog2() is removed.
- uint32_t is used throughout for capacities, instead of size_t, for
consistency with other similar values.
- changeTableSize() now takes a capacity instead of a deltaLog2, and it can now
handle !mTable.
Measurements:
- Total source code size is reduced by over 900 lines. Also, lots of existing
lines got shorter (i.e. two checks were reduced to one).
- Executable size barely changed, down by 2 KiB on Linux64. The extra branches
are compensated for by the lack of init() calls.
- Speed changed negligibly. The instruction count for Bench_Cpp_MozHash
increased from 2.84 billion to 2.89 billion but any execution time change was
well below noise.
This refactors gc::Cell derived types to start with a uintptr_t-sized
field with the low bits reserved for the GC and uses these bits for
relocation mechanism.
- JSString now stores flags in a uintptr_t. On 32-bit platforms, a
second field is used to hold length.
- Redefine JSString flag bit positions to avoid cell reserved bits.
- Forwarded Cells are now indicated by a reserved flag instead of a
magic invalid-pointer-like value.
- gc::RelocationOverlay now extends gc::Cell
- Update js::Symbol, js::Scope and js::BigInt fields to be compatible.
MozReview-Commit-ID: Cs5OavbHmqK
Add accessor methods so that underlying storage strategy can be changed
later. This patch should not change current behaviour.
MozReview-Commit-ID: IRA53TQShe6
Because (a) it's kinda weird, and (b) only used in a single test, where it can
be easily replaced with a vanilla add().
MozReview-Commit-ID: L4RoxFb7yGG
--HG--
extra : rebase_source : 515a5ede5d417686907345ad9069c6a41669dd17
It's identical to mozilla::CStringHasher.
Also fix a comment at the top of HashTable.h about CStringHasher.
--HG--
extra : rebase_source : 92176c4f6ea8041f309764b4ce0271a494853a7b
In the old days we could only share a SharedArrayBuffer, but now we
can also share WasmMemory and WasmModule objects. Rename the shell's
get/setSharedArrayBuffer as get/setSharedObject and generalize them to
handle the new types.
Leave the old names in place as aliases of the new names.
We rename /some/ uses of get/setSharedArrayBuffer in existing test
cases, but leave uses in test262 alone; we need to upstream those more
carefully.
--HG--
extra : rebase_source : 5ca04306a739249a70fc4aa8734b08e16d62f7d4
extra : source : fcd471c23cf3c1374541df766fd5aea0628fb2a5
In PLDHashTable the equivalent functions have a "Shallow" prefix, which makes
it clear that they don't measure things hanging off the table. This patch makes
mozilla::Hash{Set,Map} do likewise.
MozReview-Commit-ID: 3kwCJynhW7d
--HG--
extra : rebase_source : 9c03d11f376a9fd4cfd5cfcdc0c446c00633b210
The main change is that the patch copies js/public/HashTable.h to
mfbt/HashTable.h, and then changes it as follows.
- Changes `js` namespaces to `mozilla` (and removes some now-unnecessary
`mozilla::` qualifiers).
- Changes the default AllocPolicy from the SpiderMonkey-specific
`TempAllocPolicy` to the generic `MallocAllocPolicy`.
- Adds `#include "AllocPolicy.h"` (like mfbt/Vector.h).
- Changes `JS_DEBUG` use to `DEBUG`.
- Minor comment updates, as necessary.
js/public/HashTable.h is now tiny, holding just a few renamings of things from
the `mozilla` namespace into the `js` namespace to minimize churn elsewhere.
(Those renamings keep `TempAllocPolicy` as the default AllocPolicy for
js::Hash{Set,Map}.)
Also, various template specializations had to be moved from the `js` namespace
to the `mozilla` namespace to avoid compile errors.
MozReview-Commit-ID: GS9Qn9YeYDA
--HG--
rename : js/public/HashTable.h => mfbt/HashTable.h
Currently we have three ways of representing hash values.
- uint32_t: used in HashFunctions.h.
- PLDHashNumber: defined in PLDHashTable.{h,cpp}.
- js::HashNumber: defined in js/public/Utility.h.
Functions that create hash values with functions from HashFunctions.h use a mix
of these three types. It's a bit of a mess.
This patch introduces mozilla::HashNumber, and redefines PLDHashNumber and
js::HashNumber as synonyms. It also changes HashFunctions.h to use
mozilla::HashNumber throughout instead of uint32_t.
This leaves plenty of places that still use uint32_t that should use
mozilla::HashNumber or one of its synonyms, but I didn't want to tackle that
now.
The patch also:
- Does similar things for the constants defining the number of bits in each
hash number type.
- Moves js::HashNumber from Utility.h to HashTable.h, which is a better spot
for it. (This required changing the signature of ScrambleHashCode(); that's
ok, it'll get moved by the next patch anyway.)
MozReview-Commit-ID: EdoWlCm7OUC
--HG--
extra : rebase_source : 5b92c0c3560eb56850cd8832f8ee514d25e3c16f
Because it's more precise, and gives us more consistency.
MozReview-Commit-ID: BLYXYSHgZ7v
--HG--
extra : rebase_source : 527379499a7f2868e032982d7967005df6599bf1
Added a new CoarseType that refers to DOM nodes. Updated the trees to represent the CoarseType. Created a new type of count in the heap snapshot that sorts the data by a more descriptive type name. Created the descriptive in JS::ubi::Base.
--HG--
extra : histedit_source : be24efa4d2ccb85e82046d7cf7d2c3a1e13b1fd7
Created a runtime hook to handle DOM nodes. Specialized ubi::Concrete for nsINode-inheriting objects. Displayed outgoing nsISupports* edges on reflector JSObjects. Generated outgoing child edges from nsINodes by examining their children. Updated the UbiNodeCensus to ignore zone checks if there is no zone to be found in a node.
--HG--
extra : rebase_source : 319dccb3277a39e51a79588eac9c8f2b4ff97c2f
Created a runtime hook to handle DOM nodes. Specialized ubi::Concrete for nsINode-inheriting objects. Displayed outgoing nsISupports* edges on reflector JSObjects. Generated outgoing child edges from nsINodes by examining their children. Updated the UbiNodeCensus to ignore zone checks if there is no zone to be found in a node.
This patch adds new functions taking the arena parameter rather than overloading
existing functions, because there are already overloads of calloc that take
two size_t parameters (which arena_id_t is an alias for), so it couldn't have
been done that way, and malloc and realloc needed to be consistent with calloc.
MozReview-Commit-ID: 1MUXoCUgJWO
--HG--
extra : rebase_source : 16261ba4e802efa0bc65878d490ae9b62aa35797
Separated SimpleEdgeRange into the new UbiNodeUtils.h, updated build files, changed SimpleEdgeRange::init to SimpleEdgeRange::addTracerEdges, created bool addEdge to add new edges to the vector.
Bug 1465505 moved from PRJ_Now to mozilla::TimeStamp. As a side effect,
it introduced a few extra global constructors calls.
This patch fixes it.
MozReview-Commit-ID: 9VX83JZIyds
--HG--
extra : rebase_source : 01a22a8eea3ab224dbaa1a93d2a73ebb9ab6b6ea
IsCrossCompartmentWrapper calls IsWrapper and then had an out-of-line call to Wrapper::wrapperHandler, but that's just loading the proxy handler and we already did that in IsWrapper. Having Wrapper::wrapperHandler in the header file means the compiler can compile IsCrossCompartmentWrapper much better.