Shrink weak hash tables when adding elements, if needed.

Shrink weak hash tables when adding elements, if needed.

Hash tables containing weak references tend to be asymmetrically
handled -- Blink "user code" will add elements to the hash table,
with the garbage collector taking care of removing references
to elements that have no other strong references to keep them
alive. The weak processing of hash tables isn't capable of
shrinking and allocate a new hash table backing store while
running, hence the table entries are only cleared.

Blink code will rarely do manual removals from these
collections, which gives the hash table no opportunity
to actually shrink the capacity of the backing store.
This can lead to hash tables with a very low load factor,
the majority of the entries be deleted and empty slots.

To allow for shrinking to happen over hash tables with
weak references, add() will check if shrinking is required.

R=
BUG=

Committed: https://crrev.com/c9eb1766e3fa7c5b221ceca2c30ca402bb204014
Cr-Commit-Position: refs/heads/master@{#397667}

[sof, 2016-06-02 20:26:58]

Description was changed from

==========
Shrink weak hash tables when adding elements, if needed.

Hash tables containing weak references tend to be assymmetrically
handled -- Blink "user code" will add elements to the hash table,
with the garbage collector taking care of removing references
to elements that have no other strong references to keep them
alive. The weak processing of hash tables isn't capable of
shrinking and allocate a new hash table backing store while
running, hence the table entries are only cleared.

Blink code will rarely do manual removals from these
collections, which gives the hash table no opportunity
to actually shrink the capacity of the backing store.
This can lead to hash tables with a very low load factor,
the majority of the entries be deleted and empty slots.

To allow for shrinking to happen over hash tables with
weak references, add() will check if shrinking is required.

R=
BUG=
==========

to

==========
Shrink weak hash tables when adding elements, if needed.

Hash tables containing weak references tend to be asymmetrically
handled -- Blink "user code" will add elements to the hash table,
with the garbage collector taking care of removing references
to elements that have no other strong references to keep them
alive. The weak processing of hash tables isn't capable of
shrinking and allocate a new hash table backing store while
running, hence the table entries are only cleared.

Blink code will rarely do manual removals from these
collections, which gives the hash table no opportunity
to actually shrink the capacity of the backing store.
This can lead to hash tables with a very low load factor,
the majority of the entries be deleted and empty slots.

To allow for shrinking to happen over hash tables with
weak references, add() will check if shrinking is required.

R=
BUG=
==========

[sof, 2016-06-03 05:27:11]

sigbjornf@opera.com changed reviewers:
+ haraken@chromium.org, tkent@chromium.org

[sof, 2016-06-03 05:27:12]

please take a look.

[haraken, 2016-06-03 05:38:10]

https://codereview.chromium.org/2034883002/diff/1/third_party/WebKit/Source/w...
File third_party/WebKit/Source/wtf/HashTable.h (right):

https://codereview.chromium.org/2034883002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/wtf/HashTable.h:863: // table entries cleared. But no
shrinking of the backign store is

backing

https://codereview.chromium.org/2034883002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/wtf/HashTable.h:873: entry = rehash(m_tableSize / 2,
entry);

Maybe can we call rehash at the end of WeakProcessingHashTableHelper::process?

[sof, 2016-06-03 05:42:28]

https://codereview.chromium.org/2034883002/diff/1/third_party/WebKit/Source/w...
File third_party/WebKit/Source/wtf/HashTable.h (right):

https://codereview.chromium.org/2034883002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/wtf/HashTable.h:873: entry = rehash(m_tableSize / 2,
entry);
On 2016/06/03 05:38:10, haraken wrote:
> 
> Maybe can we call rehash at the end of WeakProcessingHashTableHelper::process?

We don't allow allocations during weak processing.

[haraken, 2016-06-03 05:46:24]

LGTM

[sof, 2016-06-03 06:17:37]

Will watch for perf fallout; not having tables with abnormal load factors is
what we want, overall.

https://codereview.chromium.org/2034883002/diff/1/third_party/WebKit/Source/w...
File third_party/WebKit/Source/wtf/HashTable.h (right):

https://codereview.chromium.org/2034883002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/wtf/HashTable.h:863: // table entries cleared. But no
shrinking of the backign store is
On 2016/06/03 05:38:10, haraken wrote:
> 
> backing

thanks, fixed

[sof, 2016-06-03 08:10:26]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2016-06-03 08:10:43]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2034883002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2034883002/20001

[commit-bot: I haz the power, 2016-06-03 08:45:13]

Description was changed from

==========
Shrink weak hash tables when adding elements, if needed.

Hash tables containing weak references tend to be asymmetrically
handled -- Blink "user code" will add elements to the hash table,
with the garbage collector taking care of removing references
to elements that have no other strong references to keep them
alive. The weak processing of hash tables isn't capable of
shrinking and allocate a new hash table backing store while
running, hence the table entries are only cleared.

Blink code will rarely do manual removals from these
collections, which gives the hash table no opportunity
to actually shrink the capacity of the backing store.
This can lead to hash tables with a very low load factor,
the majority of the entries be deleted and empty slots.

To allow for shrinking to happen over hash tables with
weak references, add() will check if shrinking is required.

R=
BUG=
==========

to

==========
Shrink weak hash tables when adding elements, if needed.

Hash tables containing weak references tend to be asymmetrically
handled -- Blink "user code" will add elements to the hash table,
with the garbage collector taking care of removing references
to elements that have no other strong references to keep them
alive. The weak processing of hash tables isn't capable of
shrinking and allocate a new hash table backing store while
running, hence the table entries are only cleared.

Blink code will rarely do manual removals from these
collections, which gives the hash table no opportunity
to actually shrink the capacity of the backing store.
This can lead to hash tables with a very low load factor,
the majority of the entries be deleted and empty slots.

To allow for shrinking to happen over hash tables with
weak references, add() will check if shrinking is required.

R=
BUG=
==========

[commit-bot: I haz the power, 2016-06-03 08:45:14]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-06-03 08:47:47]

Description was changed from

==========
Shrink weak hash tables when adding elements, if needed.

Hash tables containing weak references tend to be asymmetrically
handled -- Blink "user code" will add elements to the hash table,
with the garbage collector taking care of removing references
to elements that have no other strong references to keep them
alive. The weak processing of hash tables isn't capable of
shrinking and allocate a new hash table backing store while
running, hence the table entries are only cleared.

Blink code will rarely do manual removals from these
collections, which gives the hash table no opportunity
to actually shrink the capacity of the backing store.
This can lead to hash tables with a very low load factor,
the majority of the entries be deleted and empty slots.

To allow for shrinking to happen over hash tables with
weak references, add() will check if shrinking is required.

R=
BUG=
==========

to

==========
Shrink weak hash tables when adding elements, if needed.

Hash tables containing weak references tend to be asymmetrically
handled -- Blink "user code" will add elements to the hash table,
with the garbage collector taking care of removing references
to elements that have no other strong references to keep them
alive. The weak processing of hash tables isn't capable of
shrinking and allocate a new hash table backing store while
running, hence the table entries are only cleared.

Blink code will rarely do manual removals from these
collections, which gives the hash table no opportunity
to actually shrink the capacity of the backing store.
This can lead to hash tables with a very low load factor,
the majority of the entries be deleted and empty slots.

To allow for shrinking to happen over hash tables with
weak references, add() will check if shrinking is required.

R=
BUG=

Committed: https://crrev.com/c9eb1766e3fa7c5b221ceca2c30ca402bb204014
Cr-Commit-Position: refs/heads/master@{#397667}
==========

[commit-bot: I haz the power, 2016-06-03 08:47:48]

Patchset 2 (id:??) landed as
https://crrev.com/c9eb1766e3fa7c5b221ceca2c30ca402bb204014
Cr-Commit-Position: refs/heads/master@{#397667}