2014-06-30 19:39:45 +04:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
2012-05-21 15:12:37 +04:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2018-07-26 13:15:55 +03:00
|
|
|
// See the comment at the top of mfbt/HashTable.h for a comparison between
|
|
|
|
// PLDHashTable and mozilla::HashTable.
|
|
|
|
|
2015-09-16 06:49:53 +03:00
|
|
|
#ifndef PLDHashTable_h
|
|
|
|
#define PLDHashTable_h
|
2015-07-24 09:13:11 +03:00
|
|
|
|
Bug 1609996 - Reorder some includes affected by the previous patches. r=froydnj
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
2020-01-20 19:19:48 +03:00
|
|
|
#include <utility>
|
|
|
|
|
2020-11-23 19:12:02 +03:00
|
|
|
#include "mozilla/Assertions.h"
|
2015-04-07 21:51:35 +03:00
|
|
|
#include "mozilla/Atomics.h"
|
2018-07-26 11:52:46 +03:00
|
|
|
#include "mozilla/HashFunctions.h"
|
2021-01-29 11:39:40 +03:00
|
|
|
#include "mozilla/Maybe.h"
|
2013-06-23 16:03:39 +04:00
|
|
|
#include "mozilla/MemoryReporting.h"
|
Bug 1609996 - Reorder some includes affected by the previous patches. r=froydnj
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
2020-01-20 19:19:48 +03:00
|
|
|
#include "mozilla/fallible.h"
|
2005-08-15 22:29:55 +04:00
|
|
|
#include "nscore.h"
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2018-07-26 11:52:46 +03:00
|
|
|
using PLDHashNumber = mozilla::HashNumber;
|
|
|
|
static const uint32_t kPLDHashNumberBits = mozilla::kHashNumberBits;
|
2015-01-15 01:35:45 +03:00
|
|
|
|
2019-11-06 16:37:56 +03:00
|
|
|
#if defined(DEBUG) || defined(FUZZING)
|
2019-10-29 02:27:30 +03:00
|
|
|
# define MOZ_HASH_TABLE_CHECKS_ENABLED 1
|
|
|
|
#endif
|
|
|
|
|
2015-01-15 01:35:45 +03:00
|
|
|
class PLDHashTable;
|
|
|
|
struct PLDHashTableOps;
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2015-07-24 09:13:11 +03:00
|
|
|
// Table entry header structure.
|
|
|
|
//
|
|
|
|
// In order to allow in-line allocation of key and value, we do not declare
|
|
|
|
// either here. Instead, the API uses const void *key as a formal parameter.
|
|
|
|
// The key need not be stored in the entry; it may be part of the value, but
|
|
|
|
// need not be stored at all.
|
|
|
|
//
|
|
|
|
// Callback types are defined below and grouped into the PLDHashTableOps
|
|
|
|
// structure, for single static initialization per hash table sub-type.
|
|
|
|
//
|
|
|
|
// Each hash table sub-type should make its entry type a subclass of
|
2018-11-27 00:24:50 +03:00
|
|
|
// PLDHashEntryHdr. PLDHashEntryHdr is merely a common superclass to present a
|
|
|
|
// uniform interface to PLDHashTable clients. The zero-sized base class
|
|
|
|
// optimization, employed by all of our supported C++ compilers, will ensure
|
|
|
|
// that this abstraction does not make objects needlessly larger.
|
2014-06-27 05:35:39 +04:00
|
|
|
struct PLDHashEntryHdr {
|
Bug 1415980 - make hash keys movable and not copyable; r=erahm
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
2018-09-20 18:20:36 +03:00
|
|
|
PLDHashEntryHdr() = default;
|
|
|
|
PLDHashEntryHdr(const PLDHashEntryHdr&) = delete;
|
|
|
|
PLDHashEntryHdr& operator=(const PLDHashEntryHdr&) = delete;
|
|
|
|
PLDHashEntryHdr(PLDHashEntryHdr&&) = default;
|
|
|
|
PLDHashEntryHdr& operator=(PLDHashEntryHdr&&) = default;
|
|
|
|
|
2015-01-29 08:33:38 +03:00
|
|
|
private:
|
|
|
|
friend class PLDHashTable;
|
2005-08-12 00:47:03 +04:00
|
|
|
};
|
|
|
|
|
2019-10-29 02:27:30 +03:00
|
|
|
#ifdef MOZ_HASH_TABLE_CHECKS_ENABLED
|
2015-05-21 09:11:35 +03:00
|
|
|
|
|
|
|
// This class does three kinds of checking:
|
|
|
|
//
|
|
|
|
// - that calls to one of |mOps| or to an enumerator do not cause re-entry into
|
|
|
|
// the table in an unsafe way;
|
|
|
|
//
|
|
|
|
// - that multiple threads do not access the table in an unsafe way;
|
|
|
|
//
|
|
|
|
// - that a table marked as immutable is not modified.
|
|
|
|
//
|
|
|
|
// "Safe" here means that multiple concurrent read operations are ok, but a
|
|
|
|
// write operation (i.e. one that can cause the entry storage to be reallocated
|
|
|
|
// or destroyed) cannot safely run concurrently with another read or write
|
|
|
|
// operation. This meaning of "safe" is only partial; for example, it does not
|
|
|
|
// cover whether a single entry in the table is modified by two separate
|
|
|
|
// threads. (Doing such checking would be much harder.)
|
|
|
|
//
|
|
|
|
// It does this with two variables:
|
|
|
|
//
|
|
|
|
// - mState, which embodies a tri-stage tagged union with the following
|
|
|
|
// variants:
|
|
|
|
// - Idle
|
|
|
|
// - Read(n), where 'n' is the number of concurrent read operations
|
|
|
|
// - Write
|
|
|
|
//
|
|
|
|
// - mIsWritable, which indicates if the table is mutable.
|
|
|
|
//
|
|
|
|
class Checker {
|
|
|
|
public:
|
2019-10-29 02:27:37 +03:00
|
|
|
constexpr Checker() : mState(kIdle), mIsWritable(true) {}
|
2015-05-21 09:11:35 +03:00
|
|
|
|
|
|
|
Checker& operator=(Checker&& aOther) {
|
|
|
|
// Atomic<> doesn't have an |operator=(Atomic<>&&)|.
|
|
|
|
mState = uint32_t(aOther.mState);
|
2019-10-29 02:27:37 +03:00
|
|
|
mIsWritable = bool(aOther.mIsWritable);
|
2015-05-21 09:11:35 +03:00
|
|
|
|
|
|
|
aOther.mState = kIdle;
|
2019-10-29 02:27:37 +03:00
|
|
|
// XXX Shouldn't we set mIsWritable to true here for consistency?
|
2015-05-21 09:11:35 +03:00
|
|
|
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool IsIdle(uint32_t aState) { return aState == kIdle; }
|
|
|
|
static bool IsRead(uint32_t aState) {
|
|
|
|
return kRead1 <= aState && aState <= kReadMax;
|
|
|
|
}
|
|
|
|
static bool IsRead1(uint32_t aState) { return aState == kRead1; }
|
|
|
|
static bool IsWrite(uint32_t aState) { return aState == kWrite; }
|
|
|
|
|
|
|
|
bool IsIdle() const { return mState == kIdle; }
|
|
|
|
|
2019-10-29 02:27:37 +03:00
|
|
|
bool IsWritable() const { return mIsWritable; }
|
2015-05-21 09:11:35 +03:00
|
|
|
|
2019-10-29 02:27:37 +03:00
|
|
|
void SetNonWritable() { mIsWritable = false; }
|
2015-05-21 09:11:35 +03:00
|
|
|
|
|
|
|
// NOTE: the obvious way to implement these functions is to (a) check
|
|
|
|
// |mState| is reasonable, and then (b) update |mState|. But the lack of
|
|
|
|
// atomicity in such an implementation can cause problems if we get unlucky
|
|
|
|
// thread interleaving between (a) and (b).
|
|
|
|
//
|
|
|
|
// So instead for |mState| we are careful to (a) first get |mState|'s old
|
|
|
|
// value and assign it a new value in single atomic operation, and only then
|
|
|
|
// (b) check the old value was reasonable. This ensures we don't have
|
|
|
|
// interleaving problems.
|
|
|
|
//
|
|
|
|
// For |mIsWritable| we don't need to be as careful because it can only in
|
|
|
|
// transition in one direction (from writable to non-writable).
|
|
|
|
|
|
|
|
void StartReadOp() {
|
|
|
|
uint32_t oldState = mState++; // this is an atomic increment
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsIdle(oldState) || IsRead(oldState));
|
|
|
|
MOZ_RELEASE_ASSERT(oldState < kReadMax); // check for overflow
|
2015-05-21 09:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void EndReadOp() {
|
|
|
|
uint32_t oldState = mState--; // this is an atomic decrement
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsRead(oldState));
|
2015-05-21 09:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void StartWriteOp() {
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsWritable());
|
2015-05-21 09:11:35 +03:00
|
|
|
uint32_t oldState = mState.exchange(kWrite);
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsIdle(oldState));
|
2015-05-21 09:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void EndWriteOp() {
|
|
|
|
// Check again that the table is writable, in case it was marked as
|
|
|
|
// non-writable just after the IsWritable() assertion in StartWriteOp()
|
|
|
|
// occurred.
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsWritable());
|
2015-05-21 09:11:35 +03:00
|
|
|
uint32_t oldState = mState.exchange(kIdle);
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsWrite(oldState));
|
2015-05-21 09:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void StartIteratorRemovalOp() {
|
|
|
|
// When doing removals at the end of iteration, we go from Read1 state to
|
|
|
|
// Write and then back.
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsWritable());
|
2015-05-21 09:11:35 +03:00
|
|
|
uint32_t oldState = mState.exchange(kWrite);
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsRead1(oldState));
|
2015-05-21 09:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void EndIteratorRemovalOp() {
|
|
|
|
// Check again that the table is writable, in case it was marked as
|
|
|
|
// non-writable just after the IsWritable() assertion in
|
|
|
|
// StartIteratorRemovalOp() occurred.
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsWritable());
|
2015-05-21 09:11:35 +03:00
|
|
|
uint32_t oldState = mState.exchange(kRead1);
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsWrite(oldState));
|
2015-05-21 09:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void StartDestructorOp() {
|
|
|
|
// A destructor op is like a write, but the table doesn't need to be
|
|
|
|
// writable.
|
|
|
|
uint32_t oldState = mState.exchange(kWrite);
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsIdle(oldState));
|
2015-05-21 09:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void EndDestructorOp() {
|
|
|
|
uint32_t oldState = mState.exchange(kIdle);
|
2019-10-29 02:27:26 +03:00
|
|
|
MOZ_RELEASE_ASSERT(IsWrite(oldState));
|
2015-05-21 09:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
// Things of note about the representation of |mState|.
|
|
|
|
// - The values between kRead1..kReadMax represent valid Read(n) values.
|
|
|
|
// - kIdle and kRead1 are deliberately chosen so that incrementing the -
|
|
|
|
// former gives the latter.
|
|
|
|
// - 9999 concurrent readers should be enough for anybody.
|
|
|
|
static const uint32_t kIdle = 0;
|
|
|
|
static const uint32_t kRead1 = 1;
|
|
|
|
static const uint32_t kReadMax = 9999;
|
|
|
|
static const uint32_t kWrite = 10000;
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2020-02-27 20:39:15 +03:00
|
|
|
mozilla::Atomic<uint32_t, mozilla::SequentiallyConsistent> mState;
|
|
|
|
mozilla::Atomic<bool, mozilla::SequentiallyConsistent> mIsWritable;
|
2015-05-21 09:11:35 +03:00
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2015-07-24 09:13:11 +03:00
|
|
|
// A PLDHashTable may be allocated on the stack or within another structure or
|
|
|
|
// class. No entry storage is allocated until the first element is added. This
|
|
|
|
// means that empty hash tables are cheap, which is good because they are
|
|
|
|
// common.
|
|
|
|
//
|
|
|
|
// There used to be a long, math-heavy comment here about the merits of
|
|
|
|
// double hashing vs. chaining; it was removed in bug 1058335. In short, double
|
|
|
|
// hashing is more space-efficient unless the element size gets large (in which
|
|
|
|
// case you should keep using double hashing but switch to using pointer
|
|
|
|
// elements). Also, with double hashing, you can't safely hold an entry pointer
|
2015-07-27 05:57:23 +03:00
|
|
|
// and use it after an add or remove operation, unless you sample Generation()
|
|
|
|
// before adding or removing, and compare the sample after, dereferencing the
|
|
|
|
// entry pointer only if Generation() has not changed.
|
2015-01-15 01:35:45 +03:00
|
|
|
class PLDHashTable {
|
2014-08-26 03:56:33 +04:00
|
|
|
private:
|
2018-11-27 00:24:50 +03:00
|
|
|
// A slot represents a cached hash value and its associated entry stored in
|
|
|
|
// the hash table. The hash value and the entry are not stored contiguously.
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
struct Slot {
|
2018-11-27 00:24:50 +03:00
|
|
|
Slot(PLDHashEntryHdr* aEntry, PLDHashNumber* aKeyHash)
|
|
|
|
: mEntry(aEntry), mKeyHash(aKeyHash) {}
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
|
|
|
|
Slot(const Slot&) = default;
|
2018-11-27 00:24:50 +03:00
|
|
|
Slot(Slot&& aOther) = default;
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
|
2020-02-12 14:13:33 +03:00
|
|
|
Slot& operator=(Slot&& aOther) = default;
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
|
2018-11-27 00:24:50 +03:00
|
|
|
bool operator==(const Slot& aOther) { return mEntry == aOther.mEntry; }
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
|
2018-11-27 00:24:50 +03:00
|
|
|
PLDHashNumber KeyHash() const { return *HashPtr(); }
|
|
|
|
void SetKeyHash(PLDHashNumber aHash) { *HashPtr() = aHash; }
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
|
|
|
|
PLDHashEntryHdr* ToEntry() const { return mEntry; }
|
|
|
|
|
|
|
|
bool IsFree() const { return KeyHash() == 0; }
|
|
|
|
bool IsRemoved() const { return KeyHash() == 1; }
|
2018-11-27 00:24:50 +03:00
|
|
|
bool IsLive() const { return IsLiveHash(KeyHash()); }
|
|
|
|
static bool IsLiveHash(uint32_t aHash) { return aHash >= 2; }
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
|
2018-11-27 00:24:50 +03:00
|
|
|
void MarkFree() { *HashPtr() = 0; }
|
|
|
|
void MarkRemoved() { *HashPtr() = 1; }
|
|
|
|
void MarkColliding() { *HashPtr() |= kCollisionFlag; }
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
|
|
|
|
void Next(uint32_t aEntrySize) {
|
|
|
|
char* p = reinterpret_cast<char*>(mEntry);
|
|
|
|
p += aEntrySize;
|
|
|
|
mEntry = reinterpret_cast<PLDHashEntryHdr*>(p);
|
2018-11-27 00:24:50 +03:00
|
|
|
mKeyHash++;
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
}
|
2018-11-27 00:24:50 +03:00
|
|
|
PLDHashNumber* HashPtr() const { return mKeyHash; }
|
|
|
|
|
2018-11-27 00:24:50 +03:00
|
|
|
private:
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
PLDHashEntryHdr* mEntry;
|
2018-11-27 00:24:50 +03:00
|
|
|
PLDHashNumber* mKeyHash;
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
};
|
|
|
|
|
2015-07-27 05:57:23 +03:00
|
|
|
// This class maintains the invariant that every time the entry store is
|
|
|
|
// changed, the generation is updated.
|
2017-09-15 13:04:29 +03:00
|
|
|
//
|
2018-11-27 00:24:50 +03:00
|
|
|
// The data layout separates the cached hashes of entries and the entries
|
|
|
|
// themselves to save space. We could store the entries thusly:
|
|
|
|
//
|
|
|
|
// +--------+--------+---------+
|
|
|
|
// | entry0 | entry1 | ... |
|
|
|
|
// +--------+--------+---------+
|
|
|
|
//
|
|
|
|
// where the entries themselves contain the cached hash stored as their
|
|
|
|
// first member. PLDHashTable did this for a long time, with entries looking
|
|
|
|
// like:
|
|
|
|
//
|
|
|
|
// class PLDHashEntryHdr
|
|
|
|
// {
|
|
|
|
// PLDHashNumber mKeyHash;
|
|
|
|
// };
|
|
|
|
//
|
|
|
|
// class MyEntry : public PLDHashEntryHdr
|
|
|
|
// {
|
|
|
|
// ...
|
|
|
|
// };
|
|
|
|
//
|
|
|
|
// The problem with this setup is that, depending on the layout of
|
|
|
|
// `MyEntry`, there may be platform ABI-mandated padding between `mKeyHash`
|
|
|
|
// and the first member of `MyEntry`. This ABI-mandated padding is wasted
|
|
|
|
// space, and was surprisingly common, e.g. when MyEntry contained a single
|
|
|
|
// pointer on 64-bit platforms.
|
|
|
|
//
|
|
|
|
// As previously alluded to, the current setup stores things thusly:
|
|
|
|
//
|
|
|
|
// +-------+-------+-------+-------+--------+--------+---------+
|
|
|
|
// | hash0 | hash1 | ..... | hashN | entry0 | entry1 | ... |
|
|
|
|
// +-------+-------+-------+-------+--------+--------+---------+
|
|
|
|
//
|
|
|
|
// which contains no wasted space between the hashes themselves, and no
|
|
|
|
// wasted space between the entries themselves. malloc is guaranteed to
|
|
|
|
// return blocks of memory with at least word alignment on all of our major
|
|
|
|
// platforms. PLDHashTable mandates that the size of the hash table is
|
|
|
|
// always a power of two, so the alignment of the memory containing the
|
|
|
|
// first entry is always at least the alignment of the entire entry store.
|
|
|
|
// That means the alignment of `entry0` should be its natural alignment.
|
|
|
|
// Entries may have problems if they contain over-aligned members such as
|
|
|
|
// SIMD vector types, but this has not been a problem in practice.
|
|
|
|
//
|
2017-09-15 13:04:29 +03:00
|
|
|
// Note: It would be natural to store the generation within this class, but
|
|
|
|
// we can't do that without bloating sizeof(PLDHashTable) on 64-bit machines.
|
|
|
|
// So instead we store it outside this class, and Set() takes a pointer to it
|
|
|
|
// and ensures it is updated as necessary.
|
2015-07-27 05:57:23 +03:00
|
|
|
class EntryStore {
|
|
|
|
private:
|
|
|
|
char* mEntryStore;
|
|
|
|
|
2018-11-27 00:24:50 +03:00
|
|
|
static char* Entries(char* aStore, uint32_t aCapacity) {
|
|
|
|
return aStore + aCapacity * sizeof(PLDHashNumber);
|
|
|
|
}
|
|
|
|
|
|
|
|
char* Entries(uint32_t aCapacity) const {
|
|
|
|
return Entries(Get(), aCapacity);
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
}
|
2018-11-27 00:24:50 +03:00
|
|
|
|
2015-07-27 05:57:23 +03:00
|
|
|
public:
|
2017-09-15 13:04:29 +03:00
|
|
|
EntryStore() : mEntryStore(nullptr) {}
|
2015-07-27 05:57:23 +03:00
|
|
|
|
|
|
|
~EntryStore() {
|
|
|
|
free(mEntryStore);
|
|
|
|
mEntryStore = nullptr;
|
|
|
|
}
|
|
|
|
|
2018-11-27 00:24:50 +03:00
|
|
|
char* Get() const { return mEntryStore; }
|
2020-09-25 03:09:35 +03:00
|
|
|
bool IsAllocated() const { return !!mEntryStore; }
|
2018-11-27 00:24:50 +03:00
|
|
|
|
|
|
|
Slot SlotForIndex(uint32_t aIndex, uint32_t aEntrySize,
|
|
|
|
uint32_t aCapacity) const {
|
|
|
|
char* entries = Entries(aCapacity);
|
|
|
|
auto entry =
|
|
|
|
reinterpret_cast<PLDHashEntryHdr*>(entries + aIndex * aEntrySize);
|
|
|
|
auto hashes = reinterpret_cast<PLDHashNumber*>(Get());
|
|
|
|
return Slot(entry, &hashes[aIndex]);
|
|
|
|
}
|
|
|
|
|
|
|
|
Slot SlotForPLDHashEntry(PLDHashEntryHdr* aEntry, uint32_t aCapacity,
|
|
|
|
uint32_t aEntrySize) {
|
|
|
|
char* entries = Entries(aCapacity);
|
|
|
|
char* entry = reinterpret_cast<char*>(aEntry);
|
|
|
|
uint32_t entryOffset = entry - entries;
|
|
|
|
uint32_t slotIndex = entryOffset / aEntrySize;
|
|
|
|
return SlotForIndex(slotIndex, aEntrySize, aCapacity);
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
template <typename F>
|
|
|
|
void ForEachSlot(uint32_t aCapacity, uint32_t aEntrySize, F&& aFunc) {
|
|
|
|
ForEachSlot(Get(), aCapacity, aEntrySize, std::move(aFunc));
|
|
|
|
}
|
|
|
|
|
|
|
|
template <typename F>
|
|
|
|
static void ForEachSlot(char* aStore, uint32_t aCapacity,
|
|
|
|
uint32_t aEntrySize, F&& aFunc) {
|
2018-11-27 00:24:50 +03:00
|
|
|
char* entries = Entries(aStore, aCapacity);
|
|
|
|
Slot slot(reinterpret_cast<PLDHashEntryHdr*>(entries),
|
|
|
|
reinterpret_cast<PLDHashNumber*>(aStore));
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
for (size_t i = 0; i < aCapacity; ++i) {
|
|
|
|
aFunc(slot);
|
|
|
|
slot.Next(aEntrySize);
|
|
|
|
}
|
|
|
|
}
|
2015-07-27 05:57:23 +03:00
|
|
|
|
2017-09-15 13:04:29 +03:00
|
|
|
void Set(char* aEntryStore, uint16_t* aGeneration) {
|
2015-07-27 05:57:23 +03:00
|
|
|
mEntryStore = aEntryStore;
|
2017-09-15 13:04:29 +03:00
|
|
|
*aGeneration += 1;
|
2015-07-27 05:57:23 +03:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2017-09-15 13:04:29 +03:00
|
|
|
// These fields are packed carefully. On 32-bit platforms,
|
|
|
|
// sizeof(PLDHashTable) is 20. On 64-bit platforms, sizeof(PLDHashTable) is
|
|
|
|
// 32; 28 bytes of data followed by 4 bytes of padding for alignment.
|
2015-07-24 09:13:11 +03:00
|
|
|
const PLDHashTableOps* const mOps; // Virtual operations; see below.
|
2017-09-15 13:04:29 +03:00
|
|
|
EntryStore mEntryStore; // (Lazy) entry storage and generation.
|
|
|
|
uint16_t mGeneration; // The storage generation.
|
|
|
|
uint8_t mHashShift; // Multiplicative hash shift.
|
|
|
|
const uint8_t mEntrySize; // Number of bytes in an entry.
|
2015-07-24 09:13:11 +03:00
|
|
|
uint32_t mEntryCount; // Number of entries in table.
|
|
|
|
uint32_t mRemovedCount; // Removed entry sentinels in table.
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2019-10-29 02:27:30 +03:00
|
|
|
#ifdef MOZ_HASH_TABLE_CHECKS_ENABLED
|
2015-05-21 09:11:35 +03:00
|
|
|
mutable Checker mChecker;
|
2015-04-07 21:51:35 +03:00
|
|
|
#endif
|
|
|
|
|
2014-08-26 03:56:33 +04:00
|
|
|
public:
|
2015-07-21 03:06:38 +03:00
|
|
|
// Table capacity limit; do not exceed. The max capacity used to be 1<<23 but
|
|
|
|
// that occasionally that wasn't enough. Making it much bigger than 1<<26
|
|
|
|
// probably isn't worthwhile -- tables that big are kind of ridiculous.
|
|
|
|
// Also, the growth operation will (deliberately) fail if |capacity *
|
|
|
|
// mEntrySize| overflows a uint32_t, and mEntrySize is always at least 8
|
|
|
|
// bytes.
|
|
|
|
static const uint32_t kMaxCapacity = ((uint32_t)1 << 26);
|
|
|
|
|
|
|
|
static const uint32_t kMinCapacity = 8;
|
|
|
|
|
|
|
|
// Making this half of kMaxCapacity ensures it'll fit. Nobody should need an
|
|
|
|
// initial length anywhere nearly this large, anyway.
|
|
|
|
static const uint32_t kMaxInitialLength = kMaxCapacity / 2;
|
|
|
|
|
|
|
|
// This gives a default initial capacity of 8.
|
|
|
|
static const uint32_t kDefaultInitialLength = 4;
|
|
|
|
|
2015-06-02 11:58:58 +03:00
|
|
|
// Initialize the table with |aOps| and |aEntrySize|. The table's initial
|
|
|
|
// capacity is chosen such that |aLength| elements can be inserted without
|
|
|
|
// rehashing; if |aLength| is a power-of-two, this capacity will be
|
|
|
|
// |2*length|. However, because entry storage is allocated lazily, this
|
|
|
|
// initial capacity won't be relevant until the first element is added; prior
|
|
|
|
// to that the capacity will be zero.
|
|
|
|
//
|
|
|
|
// This will crash if |aEntrySize| and/or |aLength| are too large.
|
|
|
|
PLDHashTable(const PLDHashTableOps* aOps, uint32_t aEntrySize,
|
2015-07-21 03:06:38 +03:00
|
|
|
uint32_t aLength = kDefaultInitialLength);
|
2015-01-20 03:01:24 +03:00
|
|
|
|
2015-05-04 03:04:07 +03:00
|
|
|
PLDHashTable(PLDHashTable&& aOther)
|
2018-07-23 17:47:55 +03:00
|
|
|
// Initialize fields which are checked by the move assignment operator
|
|
|
|
// and the destructor (which the move assignment operator calls).
|
|
|
|
: mOps(nullptr), mEntryStore(), mGeneration(0), mEntrySize(0) {
|
2018-05-30 22:15:35 +03:00
|
|
|
*this = std::move(aOther);
|
2015-04-07 21:51:35 +03:00
|
|
|
}
|
|
|
|
|
2015-05-04 03:04:07 +03:00
|
|
|
PLDHashTable& operator=(PLDHashTable&& aOther);
|
|
|
|
|
2015-06-02 11:58:58 +03:00
|
|
|
~PLDHashTable();
|
|
|
|
|
2015-05-18 10:52:08 +03:00
|
|
|
// This should be used rarely.
|
2020-02-27 20:39:15 +03:00
|
|
|
const PLDHashTableOps* Ops() const { return mOps; }
|
2018-11-28 22:09:01 +03:00
|
|
|
|
2015-07-24 09:13:11 +03:00
|
|
|
// Size in entries (gross, not net of free and removed sentinels) for table.
|
|
|
|
// This can be zero if no elements have been added yet, in which case the
|
|
|
|
// entry storage will not have yet been allocated.
|
2014-08-26 03:56:33 +04:00
|
|
|
uint32_t Capacity() const {
|
2020-09-25 03:09:35 +03:00
|
|
|
return mEntryStore.IsAllocated() ? CapacityFromHashShift() : 0;
|
2014-08-26 03:56:33 +04:00
|
|
|
}
|
|
|
|
|
2014-08-26 04:29:14 +04:00
|
|
|
uint32_t EntrySize() const { return mEntrySize; }
|
|
|
|
uint32_t EntryCount() const { return mEntryCount; }
|
2017-09-15 13:04:29 +03:00
|
|
|
uint32_t Generation() const { return mGeneration; }
|
2014-08-26 03:56:33 +04:00
|
|
|
|
2015-07-24 07:43:48 +03:00
|
|
|
// To search for a |key| in |table|, call:
|
|
|
|
//
|
|
|
|
// entry = table.Search(key);
|
|
|
|
//
|
|
|
|
// If |entry| is non-null, |key| was found. If |entry| is null, key was not
|
|
|
|
// found.
|
2018-07-13 10:56:29 +03:00
|
|
|
PLDHashEntryHdr* Search(const void* aKey) const;
|
2015-07-24 07:43:48 +03:00
|
|
|
|
|
|
|
// To add an entry identified by |key| to table, call:
|
|
|
|
//
|
|
|
|
// entry = table.Add(key, mozilla::fallible);
|
|
|
|
//
|
|
|
|
// If |entry| is null upon return, then the table is severely overloaded and
|
|
|
|
// memory can't be allocated for entry storage.
|
|
|
|
//
|
2018-11-27 00:24:50 +03:00
|
|
|
// Otherwise, if the initEntry hook was provided, |entry| will be
|
|
|
|
// initialized. If the initEntry hook was not provided, the caller
|
|
|
|
// should initialize |entry| as appropriate.
|
2015-02-03 01:48:58 +03:00
|
|
|
PLDHashEntryHdr* Add(const void* aKey, const mozilla::fallible_t&);
|
2015-07-24 07:43:48 +03:00
|
|
|
|
|
|
|
// This is like the other Add() function, but infallible, and so never
|
|
|
|
// returns null.
|
2015-02-02 01:56:33 +03:00
|
|
|
PLDHashEntryHdr* Add(const void* aKey);
|
2015-07-24 07:43:48 +03:00
|
|
|
|
|
|
|
// To remove an entry identified by |key| from table, call:
|
|
|
|
//
|
|
|
|
// table.Remove(key);
|
|
|
|
//
|
|
|
|
// If |key|'s entry is found, it is cleared (via table->mOps->clearEntry).
|
2015-09-08 05:20:12 +03:00
|
|
|
// The table's capacity may be reduced afterwards.
|
2015-01-16 03:01:28 +03:00
|
|
|
void Remove(const void* aKey);
|
2014-08-26 03:56:33 +04:00
|
|
|
|
2015-09-08 05:20:12 +03:00
|
|
|
// To remove an entry found by a prior search, call:
|
|
|
|
//
|
|
|
|
// table.RemoveEntry(entry);
|
|
|
|
//
|
|
|
|
// The entry, which must be present and in use, is cleared (via
|
|
|
|
// table->mOps->clearEntry). The table's capacity may be reduced afterwards.
|
|
|
|
void RemoveEntry(PLDHashEntryHdr* aEntry);
|
|
|
|
|
2015-07-24 07:43:48 +03:00
|
|
|
// Remove an entry already accessed via Search() or Add().
|
|
|
|
//
|
|
|
|
// NB: this is a "raw" or low-level method. It does not shrink the table if
|
2015-09-08 05:20:12 +03:00
|
|
|
// it is underloaded. Don't use it unless necessary and you know what you are
|
|
|
|
// doing, and if so, please explain in a comment why it is necessary instead
|
|
|
|
// of RemoveEntry().
|
2014-08-26 03:56:33 +04:00
|
|
|
void RawRemove(PLDHashEntryHdr* aEntry);
|
|
|
|
|
2015-06-02 11:58:58 +03:00
|
|
|
// This function is equivalent to
|
2015-07-21 03:06:38 +03:00
|
|
|
// ClearAndPrepareForLength(kDefaultInitialLength).
|
2015-06-02 11:58:58 +03:00
|
|
|
void Clear();
|
|
|
|
|
|
|
|
// This function clears the table's contents and frees its entry storage,
|
|
|
|
// leaving it in a empty state ready to be used again. Afterwards, when the
|
|
|
|
// first element is added the entry storage that gets allocated will have a
|
|
|
|
// capacity large enough to fit |aLength| elements without rehashing.
|
|
|
|
//
|
|
|
|
// It's conceptually the same as calling the destructor and then re-calling
|
|
|
|
// the constructor with the original |aOps| and |aEntrySize| arguments, and
|
|
|
|
// a new |aLength| argument.
|
|
|
|
void ClearAndPrepareForLength(uint32_t aLength);
|
|
|
|
|
2015-07-30 08:28:20 +03:00
|
|
|
// Measure the size of the table's entry storage. If the entries contain
|
|
|
|
// pointers to other heap blocks, you have to iterate over the table and
|
|
|
|
// measure those separately; hence the "Shallow" prefix.
|
|
|
|
size_t ShallowSizeOfIncludingThis(mozilla::MallocSizeOf aMallocSizeOf) const;
|
2014-08-26 03:56:33 +04:00
|
|
|
|
2015-07-30 08:28:20 +03:00
|
|
|
// Like ShallowSizeOfExcludingThis(), but includes sizeof(*this).
|
|
|
|
size_t ShallowSizeOfExcludingThis(mozilla::MallocSizeOf aMallocSizeOf) const;
|
2014-08-26 03:56:33 +04:00
|
|
|
|
2015-07-24 07:43:48 +03:00
|
|
|
// Mark a table as immutable for the remainder of its lifetime. This
|
|
|
|
// changes the implementation from asserting one set of invariants to
|
|
|
|
// asserting a different set.
|
2019-10-29 02:27:30 +03:00
|
|
|
void MarkImmutable() {
|
|
|
|
#ifdef MOZ_HASH_TABLE_CHECKS_ENABLED
|
|
|
|
mChecker.SetNonWritable();
|
2014-08-26 03:56:33 +04:00
|
|
|
#endif
|
2019-10-29 02:27:30 +03:00
|
|
|
}
|
2014-08-26 03:56:33 +04:00
|
|
|
|
2015-09-15 00:23:47 +03:00
|
|
|
// If you use PLDHashEntryStub or a subclass of it as your entry struct, and
|
|
|
|
// if your entries move via memcpy and clear via memset(0), you can use these
|
|
|
|
// stub operations.
|
|
|
|
static const PLDHashTableOps* StubOps();
|
|
|
|
|
|
|
|
// The individual stub operations in StubOps().
|
2016-03-16 07:33:44 +03:00
|
|
|
static PLDHashNumber HashVoidPtrKeyStub(const void* aKey);
|
|
|
|
static bool MatchEntryStub(const PLDHashEntryHdr* aEntry, const void* aKey);
|
2015-09-15 00:23:47 +03:00
|
|
|
static void MoveEntryStub(PLDHashTable* aTable, const PLDHashEntryHdr* aFrom,
|
|
|
|
PLDHashEntryHdr* aTo);
|
|
|
|
static void ClearEntryStub(PLDHashTable* aTable, PLDHashEntryHdr* aEntry);
|
|
|
|
|
|
|
|
// Hash/match operations for tables holding C strings.
|
2016-03-16 07:33:44 +03:00
|
|
|
static PLDHashNumber HashStringKey(const void* aKey);
|
|
|
|
static bool MatchStringKey(const PLDHashEntryHdr* aEntry, const void* aKey);
|
2014-08-26 03:56:33 +04:00
|
|
|
|
2021-01-29 11:39:40 +03:00
|
|
|
class EntryHandle {
|
|
|
|
public:
|
|
|
|
EntryHandle(EntryHandle&& aOther) noexcept;
|
2021-03-25 11:34:32 +03:00
|
|
|
#ifdef MOZ_HASH_TABLE_CHECKS_ENABLED
|
2021-01-29 11:39:40 +03:00
|
|
|
~EntryHandle();
|
2021-03-25 11:34:32 +03:00
|
|
|
#endif
|
2021-01-29 11:39:40 +03:00
|
|
|
|
|
|
|
EntryHandle(const EntryHandle&) = delete;
|
|
|
|
EntryHandle& operator=(const EntryHandle&) = delete;
|
|
|
|
EntryHandle& operator=(EntryHandle&& aOther) = delete;
|
|
|
|
|
|
|
|
// Is this slot currently occupied?
|
|
|
|
bool HasEntry() const { return mSlot.IsLive(); }
|
|
|
|
|
|
|
|
explicit operator bool() const { return HasEntry(); }
|
|
|
|
|
|
|
|
// Get the entry stored in this slot. May not be called unless the slot is
|
|
|
|
// currently occupied.
|
|
|
|
PLDHashEntryHdr* Entry() {
|
|
|
|
MOZ_ASSERT(HasEntry());
|
|
|
|
return mSlot.ToEntry();
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class F>
|
|
|
|
void Insert(F&& aInitEntry) {
|
|
|
|
MOZ_ASSERT(!HasEntry());
|
|
|
|
OccupySlot();
|
|
|
|
std::forward<F>(aInitEntry)(Entry());
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the slot is currently vacant, the slot is occupied and `initEntry` is
|
|
|
|
// invoked to initialize the entry. Returns the entry stored in now-occupied
|
|
|
|
// slot.
|
|
|
|
template <class F>
|
|
|
|
PLDHashEntryHdr* OrInsert(F&& aInitEntry) {
|
|
|
|
if (!HasEntry()) {
|
|
|
|
Insert(std::forward<F>(aInitEntry));
|
|
|
|
}
|
|
|
|
return Entry();
|
|
|
|
}
|
|
|
|
|
2021-03-25 11:34:32 +03:00
|
|
|
/** Removes the entry. Note that the table won't shrink on destruction of
|
|
|
|
* the EntryHandle.
|
|
|
|
*
|
|
|
|
* \pre HasEntry()
|
|
|
|
* \post !HasEntry()
|
|
|
|
*/
|
2021-01-29 11:39:40 +03:00
|
|
|
void Remove();
|
|
|
|
|
2021-03-25 11:34:32 +03:00
|
|
|
/** Removes the entry, if it exists. Note that the table won't shrink on
|
|
|
|
* destruction of the EntryHandle.
|
|
|
|
*
|
|
|
|
* \post !HasEntry()
|
|
|
|
*/
|
2021-01-29 11:39:40 +03:00
|
|
|
void OrRemove();
|
|
|
|
|
|
|
|
private:
|
|
|
|
friend class PLDHashTable;
|
|
|
|
|
|
|
|
EntryHandle(PLDHashTable* aTable, PLDHashNumber aKeyHash, Slot aSlot);
|
|
|
|
|
|
|
|
void OccupySlot();
|
|
|
|
|
|
|
|
PLDHashTable* mTable;
|
|
|
|
PLDHashNumber mKeyHash;
|
|
|
|
Slot mSlot;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class F>
|
|
|
|
auto WithEntryHandle(const void* aKey, F&& aFunc)
|
|
|
|
-> std::invoke_result_t<F, EntryHandle&&> {
|
|
|
|
return std::forward<F>(aFunc)(MakeEntryHandle(aKey));
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class F>
|
|
|
|
auto WithEntryHandle(const void* aKey, const mozilla::fallible_t& aFallible,
|
|
|
|
F&& aFunc)
|
|
|
|
-> std::invoke_result_t<F, mozilla::Maybe<EntryHandle>&&> {
|
|
|
|
return std::forward<F>(aFunc)(MakeEntryHandle(aKey, aFallible));
|
|
|
|
}
|
|
|
|
|
2015-07-07 08:02:26 +03:00
|
|
|
// This is an iterator for PLDHashtable. Assertions will detect some, but not
|
|
|
|
// all, mid-iteration table modifications that might invalidate (e.g.
|
|
|
|
// reallocate) the entry storage.
|
|
|
|
//
|
|
|
|
// Any element can be removed during iteration using Remove(). If any
|
|
|
|
// elements are removed, the table may be resized once iteration ends.
|
2015-06-12 07:19:53 +03:00
|
|
|
//
|
|
|
|
// Example usage:
|
|
|
|
//
|
|
|
|
// for (auto iter = table.Iter(); !iter.Done(); iter.Next()) {
|
|
|
|
// auto entry = static_cast<FooEntry*>(iter.Get());
|
|
|
|
// // ... do stuff with |entry| ...
|
2015-07-07 08:02:26 +03:00
|
|
|
// // ... possibly call iter.Remove() once ...
|
2015-06-12 07:19:53 +03:00
|
|
|
// }
|
|
|
|
//
|
|
|
|
// or:
|
|
|
|
//
|
|
|
|
// for (PLDHashTable::Iterator iter(&table); !iter.Done(); iter.Next()) {
|
|
|
|
// auto entry = static_cast<FooEntry*>(iter.Get());
|
|
|
|
// // ... do stuff with |entry| ...
|
2015-07-07 08:02:26 +03:00
|
|
|
// // ... possibly call iter.Remove() once ...
|
2015-06-12 07:19:53 +03:00
|
|
|
// }
|
|
|
|
//
|
|
|
|
// The latter form is more verbose but is easier to work with when
|
|
|
|
// making subclasses of Iterator.
|
|
|
|
//
|
|
|
|
class Iterator {
|
2014-08-28 20:29:23 +04:00
|
|
|
public:
|
2015-07-07 08:02:26 +03:00
|
|
|
explicit Iterator(PLDHashTable* aTable);
|
2019-09-10 15:08:02 +03:00
|
|
|
struct EndIteratorTag {};
|
|
|
|
Iterator(PLDHashTable* aTable, EndIteratorTag aTag);
|
2015-06-12 07:19:53 +03:00
|
|
|
Iterator(Iterator&& aOther);
|
2014-08-28 20:29:23 +04:00
|
|
|
~Iterator();
|
2015-07-07 08:02:26 +03:00
|
|
|
|
2016-01-15 08:39:11 +03:00
|
|
|
// Have we finished?
|
|
|
|
bool Done() const { return mNexts == mNextsLimit; }
|
|
|
|
|
|
|
|
// Get the current entry.
|
|
|
|
PLDHashEntryHdr* Get() const {
|
|
|
|
MOZ_ASSERT(!Done());
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
MOZ_ASSERT(mCurrent.IsLive());
|
|
|
|
return mCurrent.ToEntry();
|
2016-01-15 08:39:11 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Advance to the next entry.
|
|
|
|
void Next();
|
2014-08-28 20:29:23 +04:00
|
|
|
|
2015-07-07 08:02:26 +03:00
|
|
|
// Remove the current entry. Must only be called once per entry, and Get()
|
|
|
|
// must not be called on that entry afterwards.
|
|
|
|
void Remove();
|
|
|
|
|
2019-09-10 15:08:02 +03:00
|
|
|
bool operator==(const Iterator& aOther) const {
|
|
|
|
MOZ_ASSERT(mTable == aOther.mTable);
|
|
|
|
return mNexts == aOther.mNexts;
|
|
|
|
}
|
|
|
|
|
|
|
|
Iterator Clone() const { return {*this}; }
|
|
|
|
|
2015-06-11 03:04:07 +03:00
|
|
|
protected:
|
2015-07-07 08:02:26 +03:00
|
|
|
PLDHashTable* mTable; // Main table pointer.
|
2015-06-11 03:04:07 +03:00
|
|
|
|
|
|
|
private:
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
Slot mCurrent; // Pointer to the current entry.
|
2015-07-03 10:27:27 +03:00
|
|
|
uint32_t mNexts; // Number of Next() calls.
|
|
|
|
uint32_t mNextsLimit; // Next() call limit.
|
2015-06-12 07:19:53 +03:00
|
|
|
|
2015-07-07 08:02:26 +03:00
|
|
|
bool mHaveRemoved; // Have any elements been removed?
|
2018-11-27 00:24:50 +03:00
|
|
|
uint8_t mEntrySize; // Size of entries.
|
2015-07-07 08:02:26 +03:00
|
|
|
|
2015-06-12 07:19:53 +03:00
|
|
|
bool IsOnNonLiveEntry() const;
|
2018-11-27 00:24:50 +03:00
|
|
|
|
|
|
|
void MoveToNextLiveEntry();
|
2015-06-12 07:19:53 +03:00
|
|
|
|
|
|
|
Iterator() = delete;
|
2019-09-10 15:08:02 +03:00
|
|
|
Iterator(const Iterator&);
|
2015-06-12 07:19:53 +03:00
|
|
|
Iterator& operator=(const Iterator&) = delete;
|
|
|
|
Iterator& operator=(const Iterator&&) = delete;
|
2014-08-28 20:29:23 +04:00
|
|
|
};
|
|
|
|
|
2015-07-07 08:02:26 +03:00
|
|
|
Iterator Iter() { return Iterator(this); }
|
2015-06-11 03:04:07 +03:00
|
|
|
|
2015-07-07 08:02:26 +03:00
|
|
|
// Use this if you need to initialize an Iterator in a const method. If you
|
|
|
|
// use this case, you should not call Remove() on the iterator.
|
|
|
|
Iterator ConstIter() const {
|
|
|
|
return Iterator(const_cast<PLDHashTable*>(this));
|
2015-06-11 03:04:07 +03:00
|
|
|
}
|
|
|
|
|
2014-08-26 03:56:33 +04:00
|
|
|
private:
|
2015-07-21 03:06:38 +03:00
|
|
|
static uint32_t HashShift(uint32_t aEntrySize, uint32_t aLength);
|
|
|
|
|
2015-07-21 03:15:00 +03:00
|
|
|
static const PLDHashNumber kCollisionFlag = 1;
|
|
|
|
|
2018-07-13 10:56:29 +03:00
|
|
|
PLDHashNumber Hash1(PLDHashNumber aHash0) const;
|
|
|
|
void Hash2(PLDHashNumber aHash, uint32_t& aHash2Out,
|
|
|
|
uint32_t& aSizeMaskOut) const;
|
2015-07-21 03:15:00 +03:00
|
|
|
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
static bool MatchSlotKeyhash(Slot& aSlot, const PLDHashNumber aHash);
|
|
|
|
Slot SlotForIndex(uint32_t aIndex) const;
|
2015-01-29 08:33:38 +03:00
|
|
|
|
2015-02-02 01:56:33 +03:00
|
|
|
// We store mHashShift rather than sizeLog2 to optimize the collision-free
|
|
|
|
// case in SearchTable.
|
|
|
|
uint32_t CapacityFromHashShift() const {
|
2018-07-26 11:52:46 +03:00
|
|
|
return ((uint32_t)1 << (kPLDHashNumberBits - mHashShift));
|
2015-02-02 01:56:33 +03:00
|
|
|
}
|
|
|
|
|
2018-07-13 10:56:29 +03:00
|
|
|
PLDHashNumber ComputeKeyHash(const void* aKey) const;
|
2015-01-23 02:43:18 +03:00
|
|
|
|
2015-01-30 07:18:28 +03:00
|
|
|
enum SearchReason { ForSearchOrRemove, ForAdd };
|
|
|
|
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
// Avoid using bare `Success` and `Failure`, as those names are commonly
|
|
|
|
// defined as macros.
|
|
|
|
template <SearchReason Reason, typename PLDSuccess, typename PLDFailure>
|
|
|
|
auto SearchTable(const void* aKey, PLDHashNumber aKeyHash,
|
|
|
|
PLDSuccess&& aSucess, PLDFailure&& aFailure) const;
|
2014-08-26 03:56:33 +04:00
|
|
|
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
Slot FindFreeSlot(PLDHashNumber aKeyHash) const;
|
2014-08-26 03:56:33 +04:00
|
|
|
|
|
|
|
bool ChangeTable(int aDeltaLog2);
|
2015-04-07 21:51:35 +03:00
|
|
|
|
Bug 1460674 - part 1 - change PLDHashTable internals to work on slots; r=njn
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
2018-11-27 00:24:50 +03:00
|
|
|
void RawRemove(Slot& aSlot);
|
2015-06-11 02:36:02 +03:00
|
|
|
void ShrinkIfAppropriate();
|
|
|
|
|
2021-01-29 11:39:40 +03:00
|
|
|
mozilla::Maybe<EntryHandle> MakeEntryHandle(const void* aKey,
|
|
|
|
const mozilla::fallible_t&);
|
|
|
|
|
|
|
|
EntryHandle MakeEntryHandle(const void* aKey);
|
|
|
|
|
2015-04-07 21:51:35 +03:00
|
|
|
PLDHashTable(const PLDHashTable& aOther) = delete;
|
|
|
|
PLDHashTable& operator=(const PLDHashTable& aOther) = delete;
|
2014-08-26 03:56:33 +04:00
|
|
|
};
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2016-03-16 07:33:44 +03:00
|
|
|
// Compute the hash code for a given key to be looked up, added, or removed.
|
|
|
|
// A hash code may have any PLDHashNumber value.
|
|
|
|
typedef PLDHashNumber (*PLDHashHashKey)(const void* aKey);
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2016-03-16 07:33:44 +03:00
|
|
|
// Compare the key identifying aEntry with the provided key parameter. Return
|
|
|
|
// true if keys match, false otherwise.
|
|
|
|
typedef bool (*PLDHashMatchEntry)(const PLDHashEntryHdr* aEntry,
|
2014-06-27 05:35:39 +04:00
|
|
|
const void* aKey);
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2015-07-24 09:13:11 +03:00
|
|
|
// Copy the data starting at aFrom to the new entry storage at aTo. Do not add
|
|
|
|
// reference counts for any strong references in the entry, however, as this
|
|
|
|
// is a "move" operation: the old entry storage at from will be freed without
|
|
|
|
// any reference-decrementing callback shortly.
|
2014-06-27 05:35:39 +04:00
|
|
|
typedef void (*PLDHashMoveEntry)(PLDHashTable* aTable,
|
|
|
|
const PLDHashEntryHdr* aFrom,
|
|
|
|
PLDHashEntryHdr* aTo);
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2015-07-24 09:13:11 +03:00
|
|
|
// Clear the entry and drop any strong references it holds. This callback is
|
|
|
|
// invoked by Remove(), but only if the given key is found in the table.
|
2014-06-27 05:35:39 +04:00
|
|
|
typedef void (*PLDHashClearEntry)(PLDHashTable* aTable,
|
|
|
|
PLDHashEntryHdr* aEntry);
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2018-11-27 00:24:50 +03:00
|
|
|
// Initialize a new entry. This function is called when
|
|
|
|
// Add() finds no existing entry for the given key, and must add a new one.
|
2015-02-11 20:46:40 +03:00
|
|
|
typedef void (*PLDHashInitEntry)(PLDHashEntryHdr* aEntry, const void* aKey);
|
2005-08-12 00:47:03 +04:00
|
|
|
|
2015-07-24 09:13:11 +03:00
|
|
|
// Finally, the "vtable" structure for PLDHashTable. The first four hooks
|
|
|
|
// must be provided by implementations; they're called unconditionally by the
|
2015-09-16 06:49:53 +03:00
|
|
|
// generic PLDHashTable.cpp code. Hooks after these may be null.
|
2015-07-24 09:13:11 +03:00
|
|
|
//
|
|
|
|
// Summary of allocation-related hook usage with C++ placement new emphasis:
|
|
|
|
// initEntry Call placement new using default key-based ctor.
|
|
|
|
// moveEntry Call placement new using copy ctor, run dtor on old
|
|
|
|
// entry storage.
|
|
|
|
// clearEntry Run dtor on entry.
|
|
|
|
//
|
|
|
|
// Note the reason why initEntry is optional: the default hooks (stubs) clear
|
2018-11-27 00:24:50 +03:00
|
|
|
// entry storage. On a successful Add(tbl, key), the returned entry pointer
|
|
|
|
// addresses an entry struct whose entry members are still clear (null). Add()
|
|
|
|
// callers can test such members to see whether the entry was newly created by
|
|
|
|
// the Add() call that just succeeded. If placement new or similar
|
|
|
|
// initialization is required, define an |initEntry| hook. Of course, the
|
|
|
|
// |clearEntry| hook must zero or null appropriately.
|
2015-07-24 09:13:11 +03:00
|
|
|
//
|
|
|
|
// XXX assumes 0 is null for pointer types.
|
2014-06-27 05:35:39 +04:00
|
|
|
struct PLDHashTableOps {
|
2015-07-24 09:13:11 +03:00
|
|
|
// Mandatory hooks. All implementations must provide these.
|
2014-06-27 05:35:39 +04:00
|
|
|
PLDHashHashKey hashKey;
|
|
|
|
PLDHashMatchEntry matchEntry;
|
|
|
|
PLDHashMoveEntry moveEntry;
|
|
|
|
|
2015-07-24 09:13:11 +03:00
|
|
|
// Optional hooks start here. If null, these are not called.
|
2021-03-01 11:17:47 +03:00
|
|
|
PLDHashClearEntry clearEntry;
|
2014-06-27 05:35:39 +04:00
|
|
|
PLDHashInitEntry initEntry;
|
2005-08-12 00:47:03 +04:00
|
|
|
};
|
|
|
|
|
2015-09-15 00:23:47 +03:00
|
|
|
// A minimal entry is a subclass of PLDHashEntryHdr and has a void* key pointer.
|
2015-01-29 08:33:38 +03:00
|
|
|
struct PLDHashEntryStub : public PLDHashEntryHdr {
|
|
|
|
const void* key;
|
2005-08-12 00:47:03 +04:00
|
|
|
};
|
|
|
|
|
2015-09-16 06:49:53 +03:00
|
|
|
#endif /* PLDHashTable_h */
|