Reset ThreadState weak callback stack before GCing.

Reset ThreadState weak callback stack before GCing.

In the event a thread gets to participate in more than
one GC before it manages to leave its safe point, clear
out its weak callback stack before initiating a new
GC. Otherwise we risk keeping around weak callbacks to
duplicate or dead objects.

R=
BUG=611702
Committed: https://crrev.com/423c887243774bcf76886b34c007c5d68cf93414
Cr-Commit-Position: refs/heads/master@{#397904}

[sof, 2016-06-03 18:02:54]

Description was changed from

==========
Reset ThreadState weak callback stack before GCing.

In the event a thread gets to participate in more than
one GC before it manages to leave its safe point, clear
out its weak callback stack before initiating a new
GC. Otherwise we risk keeping around callbacks to duplicate
or dead objects.

R=
BUG=611702
==========

to

==========
Reset ThreadState weak callback stack before GCing.

In the event a thread gets to participate in more than
one GC before it manages to leave its safe point, clear
out its weak callback stack before initiating a new
GC. Otherwise we risk keeping around weak callbacks to
duplicate or dead objects.

R=
BUG=611702
==========

[sof, 2016-06-03 18:05:30]

sigbjornf@opera.com changed reviewers:
+ oilpan-reviews@chromium.org

[sof, 2016-06-03 18:05:30]

please take a look.

blink_heap_unittests do reproduce these non-empty thread stacks on some tests
(ThreadedStrongification and ThreadedWeakness).

[haraken, 2016-06-03 23:30:46]

LGTM. Nice detective work!

[sof, 2016-06-04 04:50:28]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2016-06-04 04:50:43]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036803004/1

[commit-bot: I haz the power, 2016-06-04 04:54:40]

Description was changed from

==========
Reset ThreadState weak callback stack before GCing.

In the event a thread gets to participate in more than
one GC before it manages to leave its safe point, clear
out its weak callback stack before initiating a new
GC. Otherwise we risk keeping around weak callbacks to
duplicate or dead objects.

R=
BUG=611702
==========

to

==========
Reset ThreadState weak callback stack before GCing.

In the event a thread gets to participate in more than
one GC before it manages to leave its safe point, clear
out its weak callback stack before initiating a new
GC. Otherwise we risk keeping around weak callbacks to
duplicate or dead objects.

R=
BUG=611702
==========

[commit-bot: I haz the power, 2016-06-04 04:54:40]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-04 04:56:19]

Description was changed from

==========
Reset ThreadState weak callback stack before GCing.

In the event a thread gets to participate in more than
one GC before it manages to leave its safe point, clear
out its weak callback stack before initiating a new
GC. Otherwise we risk keeping around weak callbacks to
duplicate or dead objects.

R=
BUG=611702
==========

to

==========
Reset ThreadState weak callback stack before GCing.

In the event a thread gets to participate in more than
one GC before it manages to leave its safe point, clear
out its weak callback stack before initiating a new
GC. Otherwise we risk keeping around weak callbacks to
duplicate or dead objects.

R=
BUG=611702

Committed: https://crrev.com/423c887243774bcf76886b34c007c5d68cf93414
Cr-Commit-Position: refs/heads/master@{#397904}
==========

[commit-bot: I haz the power, 2016-06-04 04:56:20]

Patchset 1 (id:??) landed as
https://crrev.com/423c887243774bcf76886b34c007c5d68cf93414
Cr-Commit-Position: refs/heads/master@{#397904}