Looking good.
https://codereview.chromium.org/284773004/diff/10001/src/objects.cc
File src/objects.cc (right):
https://codereview.chromium.org/284773004/diff/10001/src/objects.cc#newcode16171
src/objects.cc:16171: table->set(EntryToValueIndex(entry), *value,
SKIP_WRITE_BARRIER);
nit: Can we add a TODO here that skipping the WB is a temporary
workaround?
https://codereview.chromium.org/284773004/diff/10001/src/objects.cc#newcode16187
src/objects.cc:16187: set(EntryToIndex(entry), *key,
SKIP_WRITE_BARRIER);
nit: Likewise.
https://codereview.chromium.org/284773004/diff/10001/test/cctest/test-heap.cc
File test/cctest/test-heap.cc (right):
https://codereview.chromium.org/284773004/diff/10001/test/cctest/test-heap.cc#newcode3915
test/cctest/test-heap.cc:3915: StartIncrementalMarking();
I don't fully understand the reason for splitting
SimuateIncrementalMarking. Would it have the same effect to call
SimulateIncrementalMarking here (before the compilation) and below
(after the compilation)? It should have the same semantics AFAICT. If my
assumption holds, then let's undo the split.
https://codereview.chromium.org/284773004/
--
--
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/d/optout.
