Clean up the marking speed heuristics. This reduces the

Clean up the marking speed heuristics.  This reduces the
max heap size on 64 bit from ca. 300Mbytes to ca. 200Mbytes
on Ulan's splay variant.  On 32 bit not much change.
Committed: http://code.google.com/p/v8/source/detail?r=9906

[ulan, 2011-11-07 17:24:50]

LGTM if comments are addressed.

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#newc...
src/incremental-marking.cc:750: bytes_scanned_ += bytes_to_process;
Should the heuristics below be active in SWEEPING state? If yes this might be
imprecise.

http://codereview.chromium.org/8494012/diff/1/src/incremental-marking.cc#newc...
src/incremental-marking.cc:823: // 1/n of the space that was available is gone
while we were
I think the condition says that 1/n is left and (n-1)/n is gone.

http://codereview.chromium.org/8494012/diff/1/src/incremental-marking.cc#newc...
src/incremental-marking.cc:842: + allocation_marking_factor_ * MB <  // Delay
before upping again.
Possible overflow in allocation_marking_factor_ * MB?

bytes_scanned / 2 saves parentheses, and should be as fast as (bytes_scanned >>
1).

Variables with descriptive names would be better than comments:
if (bytes_scanned_ / 2 < promoted_since_start_of_incremental - delay) ...

[Erik Corry, 2011-11-08 10:29:34]

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#newc...
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#newc...
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#newc...
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.