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

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

This reverts commit d4fc4a8cad0a8f94ea2a8bca7c76cebd8793395c.

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/fc6ff534003480e49dc481d9c665e961ab709c02
Cr-Commit-Position: refs/heads/master@{#32514}

[Michael Lippautz, 2015-12-02 12:25:03]

Description was changed from

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

This reverts commit d4fc4a8cad0a8f94ea2a8bca7c76cebd8793395c.

BUG=
==========

to

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

This reverts commit d4fc4a8cad0a8f94ea2a8bca7c76cebd8793395c.

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 12:31:40]

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

[Michael Lippautz, 2015-12-02 12:31:40]

PTAL. Already running on bots that failed with the broken fix on the waterfall.

[ulan, 2015-12-02 12:35:06]

lgtm

[Hannes Payer (out of office), 2015-12-02 12:45:18]

https://codereview.chromium.org/1494503004/diff/20001/src/heap/mark-compact.cc
File src/heap/mark-compact.cc (right):

https://codereview.chromium.org/1494503004/diff/20001/src/heap/mark-compact.c...
src/heap/mark-compact.cc:3765: 
The store buffer processing should go here, after sweeping aborted pages. The
dependencies are really complicated here. I have to think a little about the
reordering of this phase.

[Hannes Payer (out of office), 2015-12-02 12:56:48]

lgtm, after moving it below sweeping aborted pages.

[Michael Lippautz, 2015-12-02 13:03:59]

The CQ bit was checked by mlippautz@chromium.org

[Michael Lippautz, 2015-12-02 13:03:59]

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/1494503004/#ps40001
(title: "Reorder to the right place")

[Michael Lippautz, 2015-12-02 13:04:19]

https://codereview.chromium.org/1494503004/diff/20001/src/heap/mark-compact.cc
File src/heap/mark-compact.cc (right):

https://codereview.chromium.org/1494503004/diff/20001/src/heap/mark-compact.c...
src/heap/mark-compact.cc:3765: 
On 2015/12/02 12:45:18, Hannes Payer wrote:
> The store buffer processing should go here, after sweeping aborted pages. The
> dependencies are really complicated here. I have to think a little about the
> reordering of this phase.

Done.

[commit-bot: I haz the power, 2015-12-02 13:04:23]

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

[Michael Lippautz, 2015-12-02 13:48:46]

The CQ bit was unchecked by mlippautz@chromium.org

[Michael Lippautz, 2015-12-02 13:48:52]

The CQ bit was checked by mlippautz@chromium.org

[commit-bot: I haz the power, 2015-12-02 13:48:59]

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

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

Description was changed from

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

This reverts commit d4fc4a8cad0a8f94ea2a8bca7c76cebd8793395c.

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

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

This reverts commit d4fc4a8cad0a8f94ea2a8bca7c76cebd8793395c.

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 14:04:41]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-12-02 14:05:01]

Description was changed from

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

This reverts commit d4fc4a8cad0a8f94ea2a8bca7c76cebd8793395c.

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

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

This reverts commit d4fc4a8cad0a8f94ea2a8bca7c76cebd8793395c.

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/fc6ff534003480e49dc481d9c665e961ab709c02
Cr-Commit-Position: refs/heads/master@{#32514}
==========

[commit-bot: I haz the power, 2015-12-02 14:05:02]

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

[Michael Lippautz, 2015-12-02 14:47:14]

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

The reason for reverting is: Still failing on GC stress
 
https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20s....