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

Revert of "[heap] Clean up stale store buffer entries for aborted pages." (patchset #3 id:40001 of https://codereview.chromium.org/1494503004/ )

Reason for revert:
Still failing on GC stress
  https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/690

Original issue's description:
> 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}

TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425, chromium:564498
Committed: https://crrev.com/232276810476f8639c832ae1c772f087d4042a10
Cr-Commit-Position: refs/heads/master@{#32520}

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

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

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

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

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

Description was changed from

==========
Revert of "[heap] Clean up stale store buffer entries for aborted pages."
(patchset #3 id:40001 of https://codereview.chromium.org/1494503004/ )

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

Original issue's description:
> 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}

TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425, chromium:564498
==========

to

==========
Revert of "[heap] Clean up stale store buffer entries for aborted pages."
(patchset #3 id:40001 of https://codereview.chromium.org/1494503004/ )

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

Original issue's description:
> 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}

TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425, chromium:564498
==========

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

Committed patchset #1 (id:1)

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

Description was changed from

==========
Revert of "[heap] Clean up stale store buffer entries for aborted pages."
(patchset #3 id:40001 of https://codereview.chromium.org/1494503004/ )

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

Original issue's description:
> 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}

TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425, chromium:564498
==========

to

==========
Revert of "[heap] Clean up stale store buffer entries for aborted pages."
(patchset #3 id:40001 of https://codereview.chromium.org/1494503004/ )

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

Original issue's description:
> 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}

TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425, chromium:564498

Committed: https://crrev.com/232276810476f8639c832ae1c772f087d4042a10
Cr-Commit-Position: refs/heads/master@{#32520}
==========

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

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