create a long chain of removed sentinels. Also, when adding k to a table
where k is not mapped, but where k hashes to a chain that includes removed
sentinels, recycle the first removed sentinel in the chain for k's entry.
2. Cache cx->resolving till js_DestroyContext, to avoid high JSDHashTable
new/destroy overhead in js_LookupProperty.
3. Add NS_TraceStack to nsTraceMalloc.[ch] and clean the .c file up a bit.
to grows, shrinks, and compresses. This helps JS_DHashTableOperate callers
who hold returned entry pointers to validate those pointers and avoid having
to re-lookup an entry by its key.
- Balance that addition by removing JSDHashTable.sizeMask, which is induced by
JSDHashTable.sizeLog2 at the cost of two typically single-cycle instructions.
- Use JSDHashTable.generation in jsobj.c to avoid unsafely dereferencing an
entry pointer held across calls to JSClass.resolve from js_LookupProperty,
which may recur and add entries to cx->resolving, growing that table and
invalidating entry pointers held by earlier js_LookupProperty activations.
(bug 78121, r=jst@netscape.com, sr=jband@netscape.com, a=asa@mozilla.org)
- Don't ape java.lang.String's bogo-sampling hash function for "long" (>=16
char) strings.
- Theory and practice comment in pldhash.h helps analyze when to use double
hashing (most of the time) vs. when to use chaining.
- Subroutine ChangeTable from PL_DHashTableOperate so it can be called from
PL_DHashTableEnumerate, if the latter finds that enough entries have been
removed to be worth a shrink or compress cycle.
brendan%mozilla.org
jst%netscape.com
gerv%gerv.net
mkaply%us.ibm.com