Rename some things around incremental marking triggers

Rename some things around incremental marking triggers

R=hpayer@chromium.org
BUG=

Committed: https://crrev.com/1caa269cee2545dc935817c74f672657675b9c60
Cr-Commit-Position: refs/heads/master@{#27914}

[Erik Corry Chromium.org, 2015-04-17 10:40:41]

NextGCIsLikelyToBeFull was misnamed at this point since it would return true
when the next GC was almost certainly a scavenge.  It was never actually used to
guess the type of the next GC.

https://codereview.chromium.org/1094843002/diff/1/src/heap/heap.h
File src/heap/heap.h (left):

https://codereview.chromium.org/1094843002/diff/1/src/heap/heap.h#oldcode1245
src/heap/heap.h:1245: if (FLAG_gc_global) return true;
This is the only functional change. Previously, in --gc-global mode we would
always start incremental marking immediately after the previous GC.

This isn't really how I understand --gc-global which is described as "always
perform global GCs", ie it should just avoid new-space-only GCs.

I left in the bit about early incremental start with --stress-compaction,
because it seems like a stressy thing to do.

[Hannes Payer (out of office), 2015-04-17 10:48:17]

lgtm

https://codereview.chromium.org/1094843002/diff/1/src/heap/heap.h
File src/heap/heap.h (left):

https://codereview.chromium.org/1094843002/diff/1/src/heap/heap.h#oldcode1245
src/heap/heap.h:1245: if (FLAG_gc_global) return true;
On 2015/04/17 10:40:41, Erik Corry Chromium.org wrote:
> This is the only functional change. Previously, in --gc-global mode we would
> always start incremental marking immediately after the previous GC.
> 
> This isn't really how I understand --gc-global which is described as "always
> perform global GCs", ie it should just avoid new-space-only GCs.
> 
> I left in the bit about early incremental start with --stress-compaction,
> because it seems like a stressy thing to do.

Acknowledged.

https://codereview.chromium.org/1094843002/diff/1/src/heap/heap.h
File src/heap/heap.h (right):

https://codereview.chromium.org/1094843002/diff/1/src/heap/heap.h#newcode1244
src/heap/heap.h:1244: inline bool
HeapIsFullEnoughToStartIncrementalMarking(intptr_t limit) {
I don't feel strong about the function name.

[Erik Corry Chromium.org, 2015-04-17 10:52:25]

The CQ bit was checked by erikcorry@chromium.org

[commit-bot: I haz the power, 2015-04-17 10:52:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1094843002/1

[commit-bot: I haz the power, 2015-04-17 11:17:38]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-04-17 11:17:52]

Patchset 1 (id:??) landed as
https://crrev.com/1caa269cee2545dc935817c74f672657675b9c60
Cr-Commit-Position: refs/heads/master@{#27914}

[titzer, 2015-04-20 12:47:23]

titzer@chromium.org changed reviewers:
+ titzer@chromium.org

[titzer, 2015-04-20 12:47:24]

https://codereview.chromium.org/1094843002/diff/1/src/heap/heap.h
File src/heap/heap.h (left):

https://codereview.chromium.org/1094843002/diff/1/src/heap/heap.h#oldcode1245
src/heap/heap.h:1245: if (FLAG_gc_global) return true;
On 2015/04/17 10:48:17, Hannes Payer wrote:
> On 2015/04/17 10:40:41, Erik Corry http://Chromium.org wrote:
> > This is the only functional change. Previously, in --gc-global mode we would
> > always start incremental marking immediately after the previous GC.
> > 
> > This isn't really how I understand --gc-global which is described as "always
> > perform global GCs", ie it should just avoid new-space-only GCs.
> > 
> > I left in the bit about early incremental start with --stress-compaction,
> > because it seems like a stressy thing to do.
> 
> Acknowledged.

Your CL description claimed this was a refactoring CL. The subsequent functional
change and crashing on the waterfall on amd64 determined that was a lie.