https://codereview.chromium.org/14587008/diff/1/src/heap.cc
File src/heap.cc (right):
https://codereview.chromium.org/14587008/diff/1/src/heap.cc#newcode3867
src/heap.cc:3867: incremental_marking()->RecordWrites(new_code);
So I looked into this write-barrier and I don't think we need one here.
The reasons for this are the following ...
1) All objects reachable from the code object header are pretenured and
hence cannot be in new-space. That's why the assertion in
Heap::RecordWrites that the address is not in code-space makes sense.
2) The newly allocated code object is guaranteed to still be white after
we copied over it's contents. So we couldn't have introduced
black-to-white pointers with the block copy.
3) The newly allocated code object will eventually be scanned by the
marker before a GC (it's still white) and hence all slots that point
into evacuation candidates will be discovered.
https://codereview.chromium.org/14587008/
--
--
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.
