Bug 927272 - Do not treat strings specially when rekeying map objects; r=jonco

--HG--
extra : rebase_source : 6d5bb16f1308beec31c00bcdb31f307fe29bd01d
This commit is contained in:
Terrence Cole 2013-10-17 09:12:23 -07:00
Родитель e758cc51ba
Коммит 5c3c252d31
1 изменённых файлов: 3 добавлений и 35 удалений

Просмотреть файл

@ -474,24 +474,6 @@ class OrderedHashTable
*ep = &entry;
}
}
/*
* Change the key of the front entry without calling Ops::hash on the
* entry's current key. The caller must ensure that k has the same hash
* code that the current key had when it was inserted.
*/
void rekeyFrontWithSameHashCode(const Key &k) {
MOZ_ASSERT(valid());
#ifdef DEBUG
// Assert that k falls in the same hash bucket as the old key.
HashNumber h = Ops::hash(k) >> ht.hashShift;
Data *e = ht.hashTable[h];
while (e && e != &ht.data[i])
e = e->chain;
MOZ_ASSERT(e == &ht.data[i]);
#endif
Ops::setKey(ht.data[i].element, k);
}
};
Range all() { return Range(*this); }
@ -1101,25 +1083,11 @@ MarkKey(Range &r, const HashableValue &key, JSTracer *trc)
HashableValue newKey = key.mark(trc);
if (newKey.get() != key.get()) {
if (newKey.get().isString()) {
// GC moved a string. The key stored in the OrderedHashTable must
// be updated to point to the string's new location, but rekeyFront
// would not work because it would access the string's old
// location.
//
// So as a specially gruesome hack, overwrite the key in place.
// FIXME bug 769504.
r.rekeyFrontWithSameHashCode(newKey);
} else {
// GC moved an object. It must be rekeyed, and rekeying is safe
// because the old key's hash() method is still safe to call (it
// does not access the object's old location).
JS_ASSERT(newKey.get().isObject());
// The hash function only uses the bits of the Value, so it is safe to
// rekey even when the object or string has been modified by the GC.
r.rekeyFront(newKey);
}
}
}
void
MapObject::mark(JSTracer *trc, JSObject *obj)