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);
On 2014/05/14 08:38:30, Michael Starzinger wrote:
nit: Can we add a TODO here that skipping the WB is a temporary
workaround?
Done.
https://codereview.chromium.org/284773004/diff/10001/src/objects.cc#newcode16187
src/objects.cc:16187: set(EntryToIndex(entry), *key,
SKIP_WRITE_BARRIER);
On 2014/05/14 08:38:30, Michael Starzinger wrote:
nit: Likewise.
Done.
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();
On 2014/05/14 08:38:30, Michael Starzinger wrote:
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.
You're right! Calling SimulateIncrementalMarking at the beginning is
sufficient to reproduce the leak. I reverted this part of the change.
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.
