Add to nsTHashTable the ability to remove an already-found entry

RESOLVED FIXED in Firefox 44

Status

()

RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: njn, Assigned: njn)

Tracking

Trunk
mozilla44
Points:
---

Firefox Tracking Flags

(firefox44 fixed)

Details

Attachments

(6 attachments)

(Assignee)

Description

3 years ago
This is a follow-up to bug 1202526, which did the same thing for PLDHashTable.

Here are two common nsTHashTable usage patterns:

> Entry* entry = table.GetEntry(key);
> if (!entry) {
>     return NS_ERROR_BLAH;
> }
> table.RemoveEntry(key);

> Entry* entry = table.GetEntry(key);
> if (foo(entry)) {
>     table.RemoveEntry(key);
> }

In both cases RemoveEntry() does an unnecessary re-lookup. You could instead use RawRemoveEntry(), but it does not subsequently shrink the table if its capacity gets too low.

This bug is about adding a new function that takes an already found entry (like RawRemoveEntry()) but also shrinks the table afterwards if appropriate (like RemoveEntry()).
(Assignee)

Comment 1

3 years ago
Created attachment 8667026 [details] [diff] [review]
(part 1) - Add an overloading of nsTHashTable::RemoveEntry() that takes an already-found entry
Attachment #8667026 - Flags: review?(nfroyd)
(Assignee)

Comment 2

3 years ago
Created attachment 8667027 [details] [diff] [review]
(part 2) - Optimize nsTHashTable::RemoveEntry() usage in dom/
Attachment #8667027 - Flags: review?(bzbarsky)
(Assignee)

Comment 3

3 years ago
Created attachment 8667028 [details] [diff] [review]
(part 3) - Optimize nsTHashTable::RemoveEntry() usage in gfx/
Attachment #8667028 - Flags: review?(jmuizelaar)
(Assignee)

Comment 4

3 years ago
Created attachment 8667038 [details] [diff] [review]
(part 4) - Optimize nsTHashTable::RemoveEntry() usage in netwerk/
Attachment #8667038 - Flags: review?(mcmanus)
(Assignee)

Comment 5

3 years ago
Created attachment 8667040 [details] [diff] [review]
(part 5) - Optimize nsTHashTable::RemoveEntry() usage in security/
Attachment #8667040 - Flags: review?(dkeeler)
(Assignee)

Comment 6

3 years ago
Created attachment 8667041 [details] [diff] [review]
(part 6) - Optimize nsTHashTable::RemoveEntry() usage in toolkit/
Attachment #8667041 - Flags: review?(nfroyd)
Attachment #8667028 - Flags: review?(jmuizelaar) → review+
Attachment #8667038 - Flags: review?(mcmanus) → review?(michal.novotny)
Attachment #8667040 - Flags: review?(dkeeler) → review+
Attachment #8667026 - Flags: review?(nfroyd) → review+
Attachment #8667041 - Flags: review?(nfroyd) → review+
When reviewing the toolkit/ patch, I realized one (small) problem is that people might do something like:

Entry* e = mTable.GetEntry(x);

if (e) {
  // ...
  mTable.RemoveEntry(e);
  ...
  // do something with e, which points to something completely different
}

It looks like e will have been destroyed, which may or may not leave it in a state that is sensible, but mTable could also have been resized, which means e may also point to a valid entry...just not the entry we thought it did.

WDYT about making RemoveEntry taking an |Entry*&|, so we can null out the pointer from the hashtable code?  (Maybe as a followup bug?)  That way, people mistakenly using Entry* after removing it would get a loud error about it (a null pointer dereference), rather than things happening to work and then not...  I guess RemoveEntry should also have documentation stating that you're not supposed to use the entry after it has been removed, too.
Flags: needinfo?(n.nethercote)
(Assignee)

Comment 8

3 years ago
> WDYT about making RemoveEntry taking an |Entry*&|, so we can null out the
> pointer from the hashtable code? 

Not a bad idea...
Flags: needinfo?(n.nethercote)
Comment on attachment 8667027 [details] [diff] [review]
(part 2) - Optimize nsTHashTable::RemoveEntry() usage in dom/

r=me
Attachment #8667027 - Flags: review?(bzbarsky) → review+
Attachment #8667038 - Flags: review?(michal.novotny) → review+
You need to log in before you can comment on or make changes to this bug.