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(
On 2013/10/14 09:18:37, Michael Starzinger wrote:
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.
Ahh right - I thought code would be added to this candidate list when
contexts/closures went out of scope, but what you say makes sense. I've
updated the CL to make this counter a measure of the fraction of
crankshafted v.s. non-crankshafted code that is generated overall (not
the amount live in the heap). This should be accurate enough.
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.
