[heap] Clean up stale store buffer entries for aborted pages.

[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425, chromium:564498
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

Committed: https://crrev.com/2e7eea4aef3403969fe885e30f892d46253b3572
Cr-Commit-Position: refs/heads/master@{#32495}

[Michael Lippautz, 2015-12-02 08:36:09]

Description was changed from

==========
[heap] Clean up stale store buffer entries for aborted pages.

BUG=chromium:524425
LOG=N
==========

to

==========
[heap] Clean up stale store buffer entries for aborted pages.

BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

[Michael Lippautz, 2015-12-02 08:36:53]

mlippautz@chromium.org changed reviewers:
+ hpayer@chromium.org, ulan@chromium.org

[Michael Lippautz, 2015-12-02 08:36:53]

PTAL

[ulan, 2015-12-02 08:45:01]

lgtm

[Hannes Payer (out of office), 2015-12-02 08:46:31]

lgtm

https://codereview.chromium.org/1493653002/diff/1/src/heap/spaces.h
File src/heap/spaces.h (right):

https://codereview.chromium.org/1493653002/diff/1/src/heap/spaces.h#newcode331
src/heap/spaces.h:331: //   has been aborted and needs special handling, i.e.,
sweeper, and store
sweeper and store buffer

[Michael Lippautz, 2015-12-02 08:50:23]

Description was changed from

==========
[heap] Clean up stale store buffer entries for aborted pages.

BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

to

==========
[heap] Clean up stale store buffer entries for aborted pages.

1. Let X be the aborted slot (slot in an evacuated object in an aborted page)
2. Assume X contains pointer to Y and Y is in the new space, so X is in the
store buffer.
3. Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4. The current mark-sweep finishes. The slot X is in free space and is also in
the store buffer.
5. A string of length 9 "abcdefghi" is allocated in the new space. The string
looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is previous
garbage. Let's assume that NNNNNNN0 was pointing to a new space object before.
6. Scavenge happens.
7. Slot X is still in free space and in store buffer. [It causes scavenge of the
object Y in
store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But it is
not important].
8. Our string is promoted and is allocated over the slot X, such that NNNNNNNi
is written in X.
9. The scavenge finishes.
9. Another scavenge starts.
10. We crash in 
store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
processing slot X, because it doesn't point to valid map.

BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

[Michael Lippautz, 2015-12-02 08:52:11]

Description was changed from

==========
[heap] Clean up stale store buffer entries for aborted pages.

1. Let X be the aborted slot (slot in an evacuated object in an aborted page)
2. Assume X contains pointer to Y and Y is in the new space, so X is in the
store buffer.
3. Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4. The current mark-sweep finishes. The slot X is in free space and is also in
the store buffer.
5. A string of length 9 "abcdefghi" is allocated in the new space. The string
looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is previous
garbage. Let's assume that NNNNNNN0 was pointing to a new space object before.
6. Scavenge happens.
7. Slot X is still in free space and in store buffer. [It causes scavenge of the
object Y in
store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But it is
not important].
8. Our string is promoted and is allocated over the slot X, such that NNNNNNNi
is written in X.
9. The scavenge finishes.
9. Another scavenge starts.
10. We crash in 
store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
processing slot X, because it doesn't point to valid map.

BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

to

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

[Michael Lippautz, 2015-12-02 08:53:40]

https://codereview.chromium.org/1493653002/diff/1/src/heap/spaces.h
File src/heap/spaces.h (right):

https://codereview.chromium.org/1493653002/diff/1/src/heap/spaces.h#newcode331
src/heap/spaces.h:331: //   has been aborted and needs special handling, i.e.,
sweeper, and store
On 2015/12/02 08:46:31, Hannes Payer wrote:
> sweeper and store buffer

Done.

[Michael Lippautz, 2015-12-02 08:53:58]

The CQ bit was checked by mlippautz@chromium.org

[Michael Lippautz, 2015-12-02 08:53:58]

The patchset sent to the CQ was uploaded after l-g-t-m from hpayer@chromium.org,
ulan@chromium.org
Link to the patchset: https://codereview.chromium.org/1493653002/#ps40001
(title: "Addressed Hannes comment")

[commit-bot: I haz the power, 2015-12-02 08:54:09]

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

[Michael Lippautz, 2015-12-02 09:01:41]

Description was changed from

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

to

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425,chromium:564498
LOG=N
R=hpayer@chromium.org,ulan@chromium.org
==========

[Michael Lippautz, 2015-12-02 09:01:51]

Description was changed from

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425,chromium:564498
LOG=N
R=hpayer@chromium.org,ulan@chromium.org
==========

to

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425,chromium:564498
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

[Michael Lippautz, 2015-12-02 09:06:37]

The CQ bit was unchecked by mlippautz@chromium.org

[Hannes Payer (out of office), 2015-12-02 09:17:43]

awesome! lgtm

[Michael Lippautz, 2015-12-02 09:20:05]

The CQ bit was checked by mlippautz@chromium.org

[Michael Lippautz, 2015-12-02 09:20:05]

The patchset sent to the CQ was uploaded after l-g-t-m from ulan@chromium.org
Link to the patchset: https://codereview.chromium.org/1493653002/#ps60001
(title: "Remove explicit filter call for aborted pages.")

[commit-bot: I haz the power, 2015-12-02 09:20:08]

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

[commit-bot: I haz the power, 2015-12-02 09:39:23]

Description was changed from

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425,chromium:564498
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

to

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425,chromium:564498
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

[commit-bot: I haz the power, 2015-12-02 09:39:24]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-12-02 09:39:39]

Description was changed from

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425,chromium:564498
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
==========

to

==========
[heap] Clean up stale store buffer entries for aborted pages.

1.  Let X be the aborted slot (slot in an evacuated object in an aborted page)
2.  Assume X contains pointer to Y and Y is in the new space, so X is in the
    store buffer.
3.  Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4.  The current mark-sweep finishes. The slot X is in free space and is also in
    the store buffer.
5.  A string of length 9 "abcdefghi" is allocated in the new space. The string
    looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
    previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
    object before.
6.  Scavenge happens.
7.  Slot X is still in free space and in store buffer. [It causes scavenge of
    the object Y in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
    it is not important].
8.  Our string is promoted and is allocated over the slot X, such that NNNNNNNi
    is written in X.
9.  The scavenge finishes.
9.  Another scavenge starts.
10. We crash in
    store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
    processing slot X, because it doesn't point to valid map.

BUG=chromium:524425,chromium:564498
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

Committed: https://crrev.com/2e7eea4aef3403969fe885e30f892d46253b3572
Cr-Commit-Position: refs/heads/master@{#32495}
==========

[commit-bot: I haz the power, 2015-12-02 09:39:40]

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

[Michael Lippautz, 2015-12-02 11:43:15]

A revert of this CL (patchset #4 id:60001) has been created in
https://codereview.chromium.org/1489243004/ by mlippautz@chromium.org.

The reason for reverting is: Not completely correct fix..