http://codereview.chromium.org/8494012/diff/1/src/incremental-marking.cc File src/incremental-marking.cc (right):
http://codereview.chromium.org/8494012/diff/1/src/incremental-marking.cc#newcode750 src/incremental-marking.cc:750: bytes_scanned_ += bytes_to_process; On 2011/11/07 17:24:50, ulan wrote:
Should the heuristics below be active in SWEEPING state? If yes this
might be
imprecise.
Added a reset of this variable when we start marking, and a change to not increase the speed of marking until we start marking. http://codereview.chromium.org/8494012/diff/1/src/incremental-marking.cc#newcode823 src/incremental-marking.cc:823: // 1/n of the space that was available is gone while we were On 2011/11/07 17:24:50, ulan wrote:
I think the condition says that 1/n is left and (n-1)/n is gone.
Done. http://codereview.chromium.org/8494012/diff/1/src/incremental-marking.cc#newcode842 src/incremental-marking.cc:842: + allocation_marking_factor_ * MB < // Delay before upping again. On 2011/11/07 17:24:50, ulan wrote:
Possible overflow in allocation_marking_factor_ * MB?
Reduced max allocation marking factor to 1000 to avoid this.
bytes_scanned / 2 saves parentheses, and should be as fast as
(bytes_scanned >>
1).
Done.
Variables with descriptive names would be better than comments: if (bytes_scanned_ / 2 < promoted_since_start_of_incremental - delay)
... Done. http://codereview.chromium.org/8494012/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
