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#oldcode879
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).
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.
