Perform incremental marking step after free-list allocation and clean-up incremental marking start …

Perform incremental marking step after free-list allocation and clean-up incremental marking start condition.


BUG=

Committed: https://code.google.com/p/v8/source/detail?r=14564

[Michael Starzinger, 2013-05-07 08:04:29]

Maeh ...

https://codereview.chromium.org/14634007/diff/1/src/incremental-marking.cc
File src/incremental-marking.cc (left):

https://codereview.chromium.org/14634007/diff/1/src/incremental-marking.cc#ol...
src/incremental-marking.cc:879: Start();
Let's play it safe and start the incremental marker with PREVENT_COMPACTION
here. It should be possible to start with compaction here but I see a load of
sick bugs coming our way.

https://codereview.chromium.org/14634007/diff/1/src/spaces.cc
File src/spaces.cc (right):

https://codereview.chromium.org/14634007/diff/1/src/spaces.cc#newcode2318
src/spaces.cc:2318: owner_->Free(owner_->top(), old_linear_size);
As discussed offline: We also need to make sure that the bump pointer are is not
accidentally on an evacuation candidate and pushed back onto the free-list after
marking started. We need to keep this in mind when moving around the old-space
step as well.

https://codereview.chromium.org/14634007/diff/1/src/spaces.cc#newcode2327
src/spaces.cc:2327: // The old-space-step might have finished sweeping and
restarted marking.
This comment explains it.

https://codereview.chromium.org/14634007/diff/1/src/spaces.cc#newcode2360
src/spaces.cc:2360: owner_->heap()->incremental_marking()->OldSpaceStep(
This is not safe as it might turn there page where new_node is located into an
evacuation candidate. See the comment above. This is needed when we skip
incremental write-barrier on white objects (i.e. WhitenessWitness).

[Hannes Payer (out of office), 2013-05-07 09:04:44]

https://codereview.chromium.org/14634007/diff/1/src/incremental-marking.cc
File src/incremental-marking.cc (left):

https://codereview.chromium.org/14634007/diff/1/src/incremental-marking.cc#ol...
src/incremental-marking.cc:879: Start();
On 2013/05/07 08:04:29, Michael Starzinger wrote:
> Let's play it safe and start the incremental marker with PREVENT_COMPACTION
> here. It should be possible to start with compaction here but I see a load of
> sick bugs coming our way.

Done.

https://codereview.chromium.org/14634007/diff/1/src/spaces.cc
File src/spaces.cc (right):

https://codereview.chromium.org/14634007/diff/1/src/spaces.cc#newcode2318
src/spaces.cc:2318: owner_->Free(owner_->top(), old_linear_size);
On 2013/05/07 08:04:29, Michael Starzinger wrote:
> As discussed offline: We also need to make sure that the bump pointer are is
not
> accidentally on an evacuation candidate and pushed back onto the free-list
after
> marking started. We need to keep this in mind when moving around the old-space
> step as well.

Done.

https://codereview.chromium.org/14634007/diff/1/src/spaces.cc#newcode2360
src/spaces.cc:2360: owner_->heap()->incremental_marking()->OldSpaceStep(
On 2013/05/07 08:04:29, Michael Starzinger wrote:
> This is not safe as it might turn there page where new_node is located into an
> evacuation candidate. See the comment above. This is needed when we skip
> incremental write-barrier on white objects (i.e. WhitenessWitness).

Done.

[Michael Starzinger, 2013-05-07 09:47:47]

LGTM.

[Hannes Payer (out of office), 2013-05-07 09:48:49]

Committed patchset #5 manually as r14564 (presubmit successful).