A hash table supporting full concurrency of retrievals and
high expected concurrency for updates. This class obeys the
same functional specification as java.util.Hashtable, and
includes versions of methods corresponding to each method of
Hashtable. However, even though all operations are
thread-safe, retrieval operations do not entail locking,
and there is not any support for locking the entire table
in a way that prevents all access. This class is fully
interoperable with Hashtable in programs that rely on its
thread safety but not on its synchronization details.

Retrieval operations (including get) generally do not
block, so may overlap with update operations (including put
and remove). Retrievals reflect the results of the most
recently completed update operations holding upon their
onset. (More formally, an update operation for a given key bears a
happens-before relation with any (non-null) retrieval for
that key reporting the updated value.) For aggregate operations
such as putAll and clear, concurrent retrievals may
reflect insertion or removal of only some entries. Similarly,
Iterators and Enumerations return elements reflecting the state of
the hash table at some point at or since the creation of the
iterator/enumeration. They do not throw java.util.ConcurrentModificationException. However, iterators are designed
to be used by only one thread at a time. Bear in mind that the
results of aggregate status methods including size, isEmpty, and containsValue are typically useful only when
a map is not undergoing concurrent updates in other threads.
Otherwise the results of these methods reflect transient states
that may be adequate for monitoring or estimation purposes, but not
for program control.

The table is dynamically expanded when there are too many
collisions (i.e., keys that have distinct hash codes but fall into
the same slot modulo the table size), with the expected average
effect of maintaining roughly two bins per mapping (corresponding
to a 0.75 load factor threshold for resizing). There may be much
variance around this average as mappings are added and removed, but
overall, this maintains a commonly accepted time/space tradeoff for
hash tables. However, resizing this or any other kind of hash
table may be a relatively slow operation. When possible, it is a
good idea to provide a size estimate as an optional initialCapacity constructor argument. An additional optional
loadFactor constructor argument provides a further means of
customizing initial table capacity by specifying the table density
to be used in calculating the amount of space to allocate for the
given number of elements. Also, for compatibility with previous
versions of this class, constructors may optionally specify an
expected concurrencyLevel as an additional hint for
internal sizing. Note that using many keys with exactly the same
hashCode() is a sure way to slow down performance of any
hash table. To ameliorate impact, when keys are java.lang.Comparable,
this class may use comparison order among keys to help break ties.

ConcurrentHashMapV8s support a set of sequential and parallel bulk
operations that are designed
to be safely, and often sensibly, applied even with maps that are
being concurrently updated by other threads; for example, when
computing a snapshot summary of the values in a shared registry.
There are three kinds of operation, each with four forms, accepting
functions with Keys, Values, Entries, and (Key, Value) arguments
and/or return values. Because the elements of a EquivalentConcurrentHashMapV8
are not ordered in any particular way, and may be processed in
different orders in different parallel executions, the correctness
of supplied functions should not depend on any ordering, or on any
other objects or values that may transiently change while
computation is in progress; and except for forEach actions, should
ideally be side-effect-free. Bulk operations on java.util.Map.Entry
objects do not support method setValue.

forEach: Perform a given action on each element.
A variant form applies a given transformation on each element
before performing the action.

search: Return the first available non-null result of
applying a given function on each element; skipping further
search when a result is found.

reduce: Accumulate each element. The supplied reduction
function cannot rely on ordering (more formally, it should be
both associative and commutative). There are five variants:

Plain reductions. (There is not a form of this method for
(key, value) function arguments since there is no corresponding
return type.)

Mapped reductions that accumulate the results of a given
function applied to each element.

Reductions to scalar doubles, longs, and ints, using a
given basis value.

These bulk operations accept a parallelismThreshold
argument. Methods proceed sequentially if the current map size is
estimated to be less than the given threshold. Using a value of
Long.MAX_VALUE suppresses all parallelism. Using a value
of 1 results in maximal parallelism by partitioning into
enough subtasks to fully utilize the ForkJoinPool.commonPool() that is used for all parallel
computations. Normally, you would initially choose one of these
extreme values, and then measure performance of using in-between
values that trade off overhead versus throughput.

The concurrency properties of bulk operations follow
from those of EquivalentConcurrentHashMapV8: Any non-null result returned
from get(key) and related access methods bears a
happens-before relation with the associated insertion or
update. The result of any bulk operation reflects the
composition of these per-element relations (but is not
necessarily atomic with respect to the map as a whole unless it
is somehow known to be quiescent). Conversely, because keys
and values in the map are never null, null serves as a reliable
atomic indicator of the current lack of any result. To
maintain this property, null serves as an implicit basis for
all non-scalar reduction operations. For the double, long, and
int versions, the basis should be one that, when combined with
any other value, returns that other value (more formally, it
should be the identity element for the reduction). Most common
reductions have these properties; for example, computing a sum
with basis 0 or a minimum with basis MAX_VALUE.

Search and transformation functions provided as arguments
should similarly return null to indicate the lack of any result
(in which case it is not used). In the case of mapped
reductions, this also enables transformations to serve as
filters, returning null (or, in the case of primitive
specializations, the identity basis) if the element should not
be combined. You can create compound transformations and
filterings by composing them yourself under this "null means
there is nothing there now" rule before using them in search or
reduce operations.

Methods accepting and/or returning Entry arguments maintain
key-value associations. They may be useful for example when
finding the key for the greatest value. Note that "plain" Entry
arguments can be supplied using new
AbstractMap.SimpleEntry(k,v).

Bulk operations may complete abruptly, throwing an
exception encountered in the application of a supplied
function. Bear in mind when handling such exceptions that other
concurrently executing functions could also have thrown
exceptions, or would have done so if the first exception had
not occurred.

Speedups for parallel compared to sequential forms are common
but not guaranteed. Parallel operations involving brief functions
on small maps may execute more slowly than sequential forms if the
underlying work to parallelize the computation is more expensive
than the computation itself. Similarly, parallelization may not
lead to much actual parallelism if all processors are busy
performing unrelated tasks.

All arguments to all task methods must be non-null.

jsr166e note: During transition, this class
uses nested functional interfaces with different names but the
same forms as those expected for JDK8.

This class is a member of the
Java Collections Framework.
NOTE: This map has been tweaked so that equality and hash code
calculations are done based on a passed org.infinispan.commons.equivalence.Equivalence function
implementation for keys and values, as opposed to relying on their own
equals/hashCode/toString implementations. This is handy when using
key/values whose mentioned methods cannot be overriden, i.e. arrays,
and in situations where users want to avoid using wrapper objects.
To help with future revisions of this class, changes other than
constructor changes have been marked with 'EQUIVALENCE_MOD' comment.

The largest possible table capacity. This value must be
exactly 1<<30 to stay within Java array allocation and indexing
bounds for power of two table sizes, and is further required
because the top two bits of 32bit hash fields are used for
control purposes.

The load factor for this table. Overrides of this value in
constructors affect only the initial table capacity. The
actual floating point value isn't normally used -- it is
simpler to use expressions such as n - (n >>> 2) for
the associated resizing threshold.

The bin count threshold for using a tree rather than list for a
bin. Bins are converted to trees when adding an element to a
bin with at least this many nodes. The value must be greater
than 2, and should be at least 8 to mesh with assumptions in
tree removal about conversion back to plain bins upon
shrinkage.

The smallest table capacity for which bins may be treeified.
(Otherwise the table is resized if too many nodes in a bin.)
The value should be at least 4 * TREEIFY_THRESHOLD to avoid
conflicts between resizing and treeification thresholds.

Minimum number of rebinnings per transfer step. Ranges are
subdivided to allow multiple resizer threads. This value
serves as a lower bound to avoid resizers encountering
excessive memory contention. The value should be at least
DEFAULT_CAPACITY.

Key-value entry. This class is never exported out as a
user-mutable Map.Entry (i.e., one supporting setValue; see
MapEntry below), but can be used for read-only traversals used
in bulk tasks. Subclasses of Node with a negative hash field
are special, and contain null keys and values (but are never
exported). Otherwise, keys and vals are never null.

Spreads (XORs) higher bits of hash to lower and also forces top
bit to 0. Because the table uses power-of-two masking, sets of
hashes that vary only in bits above the current mask will
always collide. (Among known examples are sets of Float keys
holding consecutive whole numbers in small tables.) So we
apply a transform that spreads the impact of higher bits
downward. There is a tradeoff between speed, utility, and
quality of bit-spreading. Because many common sets of hashes
are already reasonably distributed (so don't benefit from
spreading), and because we use trees to handle large sets of
collisions in bins, we just XOR some shifted bits in the
cheapest possible way to reduce systematic lossage, as well as
to incorporate impact of the highest bits that would otherwise
never be used in index calculations because of table bounds.

Table initialization and resizing control. When negative, the
table is being initialized or resized: -1 for initialization,
else -(1 + the number of active resizing threads). Otherwise,
when table is null, holds the initial table size to use upon
creation, or 0 for default. After initialization, holds the
next element count value upon which to resize the table.

Returns a java.util.Set view of the keys contained in this map.
The set is backed by the map, so changes to the map are
reflected in the set, and vice-versa. The set supports element
removal, which removes the corresponding mapping from this map,
via the Iterator.remove, Set.remove,
removeAll, retainAll, and clear
operations. It does not support the add or
addAll operations.

The view's iterator is a "weakly consistent" iterator
that will never throw java.util.ConcurrentModificationException,
and guarantees to traverse elements as they existed upon
construction of the iterator, and may (but is not guaranteed to)
reflect any modifications subsequent to construction.

Returns a java.util.Collection view of the values contained in this map.
The collection is backed by the map, so changes to the map are
reflected in the collection, and vice-versa. The collection
supports element removal, which removes the corresponding
mapping from this map, via the Iterator.remove,
Collection.remove, removeAll,
retainAll, and clear operations. It does not
support the add or addAll operations.

The view's iterator is a "weakly consistent" iterator
that will never throw java.util.ConcurrentModificationException,
and guarantees to traverse elements as they existed upon
construction of the iterator, and may (but is not guaranteed to)
reflect any modifications subsequent to construction.

Returns a java.util.Set view of the mappings contained in this map.
The set is backed by the map, so changes to the map are
reflected in the set, and vice-versa. The set supports element
removal, which removes the corresponding mapping from the map,
via the Iterator.remove, Set.remove,
removeAll, retainAll, and clear
operations.

The view's iterator is a "weakly consistent" iterator
that will never throw java.util.ConcurrentModificationException,
and guarantees to traverse elements as they existed upon
construction of the iterator, and may (but is not guaranteed to)
reflect any modifications subsequent to construction.

Returns a string representation of this map. The string
representation consists of a list of key-value mappings (in no
particular order) enclosed in braces ("{}"). Adjacent
mappings are separated by the characters ", " (comma
and space). Each key-value mapping is rendered as the key
followed by an equals sign ("=") followed by the
associated value.

Compares the specified object with this map for equality.
Returns true if the given object is a map with the same
mappings as this map. This operation may return misleading
results if either map is concurrently modified during execution
of this method.