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#oldcode879
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.
https://codereview.chromium.org/14634007/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
