One central comment about the way the accounting is done.
https://codereview.chromium.org/27023003/diff/3001/src/heap.h
File src/heap.h (right):
https://codereview.chromium.org/27023003/diff/3001/src/heap.h#newcode2374
src/heap.h:2374: intptr_t full_codegen_bytes_;
nit: I know the existing code is not consistent about that at all, but I
think these should be size_t here.
https://codereview.chromium.org/27023003/diff/3001/src/mark-compact.cc
File src/mark-compact.cc (right):
https://codereview.chromium.org/27023003/diff/3001/src/mark-compact.cc#newcode1010
src/mark-compact.cc:1010: isolate_->heap()->DecrementCodeGeneratedBytes(
IIUC, this tries to keep the new code-bytes counters in the heap
accurate. Unfortunately this is not possible as code can just become
unreachable (e.g. closure becomes unreachable, whole context becomes
unreachable). In general there is no place that visits "dead code"
before it's memory is reclaimed. The flushed code is just a subset of
the code being reclaimed.
We should clarify what this new counter actually wants to represent. If
we really need a fully accurate number, one accurate way to track it
would be to reset it to zero before marking starts and then let the
tracer count anew for every GC cycle. But that is hard to get right,
especially in light of incremental marking, where the same object might
be visited more than once.
I would split this part out in a separate CL, as it is not entirely
trivial to get this accounting right.
https://codereview.chromium.org/27023003/
--
--
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.
