[heap] Ensure finalization of incremental marking even if all allocations

[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

Now before expanding the heap we check if we are above the allocation limit
and the incremental marking needs to be finalized. If so we do not expand
the heap and force GC, which will finalize the incremental marking.
The check is performed for paged spaces and large-object space.

BUG=chromium:670675
Committed: https://crrev.com/fdc0aa0c97952e56686157b1023a8085885357b4
Cr-Commit-Position: refs/heads/master@{#41524}

[ulan, 2016-12-05 21:11:45]

Description was changed from

==========
[heap] Ensure finalization of incremental marking if all allocations
come from runtime.

BUG=chromium:670675
==========

to

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

The changes:
- Before expanding the heap we check if we are above the allocation limit
  and the incremental marking needs to be finalized. If so we do not expand
  the heap and force GC, which will finalize the incremental marking.
- Before doing scavenge we check if the incremental marking needs finalization.
  If so, we switch to mark-compact instead of scavenger.

BUG=chromium:670675
==========

[ulan, 2016-12-05 21:12:30]

Description was changed from

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

The changes:
- Before expanding the heap we check if we are above the allocation limit
  and the incremental marking needs to be finalized. If so we do not expand
  the heap and force GC, which will finalize the incremental marking.
- Before doing scavenge we check if the incremental marking needs finalization.
  If so, we switch to mark-compact instead of scavenger.

BUG=chromium:670675
==========

to

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

The changes:
- Before expanding the heap we check if we are above the allocation limit
  and the incremental marking needs to be finalized. If so we do not expand
  the heap and force GC, which will finalize the incremental marking.
  The check is performed for paged spaces and large-object space.
- Before doing scavenge we check if the incremental marking needs finalization.
  If so, we switch to mark-compact instead of scavenger.

BUG=chromium:670675
==========

[ulan, 2016-12-05 21:14:07]

Description was changed from

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

The changes:
- Before expanding the heap we check if we are above the allocation limit
  and the incremental marking needs to be finalized. If so we do not expand
  the heap and force GC, which will finalize the incremental marking.
  The check is performed for paged spaces and large-object space.
- Before doing scavenge we check if the incremental marking needs finalization.
  If so, we switch to mark-compact instead of scavenger.

BUG=chromium:670675
==========

to

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.
Performing GC at max capacity can often lead to OOM crash.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

The changes:
- Before expanding the heap we check if we are above the allocation limit
  and the incremental marking needs to be finalized. If so we do not expand
  the heap and force GC, which will finalize the incremental marking.
  The check is performed for paged spaces and large-object space.
- Before doing scavenge we check if the incremental marking needs finalization.
  If so, we switch to mark-compact instead of scavenger.

BUG=chromium:670675
==========

[ulan, 2016-12-05 21:14:19]

Description was changed from

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.
Performing GC at max capacity can often lead to OOM crash.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

The changes:
- Before expanding the heap we check if we are above the allocation limit
  and the incremental marking needs to be finalized. If so we do not expand
  the heap and force GC, which will finalize the incremental marking.
  The check is performed for paged spaces and large-object space.
- Before doing scavenge we check if the incremental marking needs finalization.
  If so, we switch to mark-compact instead of scavenger.

BUG=chromium:670675
==========

to

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

The changes:
- Before expanding the heap we check if we are above the allocation limit
  and the incremental marking needs to be finalized. If so we do not expand
  the heap and force GC, which will finalize the incremental marking.
  The check is performed for paged spaces and large-object space.
- Before doing scavenge we check if the incremental marking needs finalization.
  If so, we switch to mark-compact instead of scavenger.

BUG=chromium:670675
==========

[ulan, 2016-12-05 21:18:15]

ulan@chromium.org changed reviewers:
+ hpayer@chromium.org, mlippautz@chromium.org

[ulan, 2016-12-05 21:18:16]

ptal

https://codereview.chromium.org/2552613004/diff/80001/src/heap/heap.h
File src/heap/heap.h (right):

https://codereview.chromium.org/2552613004/diff/80001/src/heap/heap.h#newcode...
src/heap/heap.h:1861: bool ShouldExpandOldGenerationOnSlowAllocation();
Renaming because I call this function before expanding the large object space
(and there is no allocation failure).

https://codereview.chromium.org/2552613004/diff/80001/src/heap/incremental-ma...
File src/heap/incremental-marking.cc (right):

https://codereview.chromium.org/2552613004/diff/80001/src/heap/incremental-ma...
src/heap/incremental-marking.cc:1041: !heap()->MarkingDequesAreEmpty());
Michael: do you approve this change?

[ulan, 2016-12-06 10:23:04]

The CQ bit was checked by ulan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-06 10:23:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-06 10:39:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-06 10:39:15]

Dry run: Try jobs failed on following builders:
  v8_linux64_asan_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng/buil...)
  v8_linux64_asan_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng_trig...)

[ulan, 2016-12-06 11:00:47]

Description was changed from

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

The changes:
- Before expanding the heap we check if we are above the allocation limit
  and the incremental marking needs to be finalized. If so we do not expand
  the heap and force GC, which will finalize the incremental marking.
  The check is performed for paged spaces and large-object space.
- Before doing scavenge we check if the incremental marking needs finalization.
  If so, we switch to mark-compact instead of scavenger.

BUG=chromium:670675
==========

to

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

Now before expanding the heap we check if we are above the allocation limit
and the incremental marking needs to be finalized. If so we do not expand
the heap and force GC, which will finalize the incremental marking.
The check is performed for paged spaces and large-object space.

BUG=chromium:670675
==========

[ulan, 2016-12-06 11:00:54]

The CQ bit was checked by ulan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-06 11:01:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-06 11:28:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-06 11:28:16]

Dry run: This issue passed the CQ dry run.

[Michael Lippautz, 2016-12-06 13:33:33]

lgtm

[ulan, 2016-12-06 13:34:34]

The CQ bit was checked by ulan@chromium.org

[ulan, 2016-12-06 13:34:35]

The patchset sent to the CQ was uploaded after l-g-t-m from
mlippautz@chromium.org
Link to the patchset: https://codereview.chromium.org/2552613004/#ps120001
(title: "revert marking change")

[commit-bot: I haz the power, 2016-12-06 13:34:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-06 14:06:11]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1481031274660420,
"parent_rev": "904e235aa4bae2337b8d36cec90de29503cabcce", "commit_rev":
"d962cb7bbc63f3eb469580a82ec54b2bd164f4bf"}

[commit-bot: I haz the power, 2016-12-06 14:06:15]

Description was changed from

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

Now before expanding the heap we check if we are above the allocation limit
and the incremental marking needs to be finalized. If so we do not expand
the heap and force GC, which will finalize the incremental marking.
The check is performed for paged spaces and large-object space.

BUG=chromium:670675
==========

to

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

Now before expanding the heap we check if we are above the allocation limit
and the incremental marking needs to be finalized. If so we do not expand
the heap and force GC, which will finalize the incremental marking.
The check is performed for paged spaces and large-object space.

BUG=chromium:670675
==========

[commit-bot: I haz the power, 2016-12-06 14:06:16]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-12-06 14:06:48]

Description was changed from

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

Now before expanding the heap we check if we are above the allocation limit
and the incremental marking needs to be finalized. If so we do not expand
the heap and force GC, which will finalize the incremental marking.
The check is performed for paged spaces and large-object space.

BUG=chromium:670675
==========

to

==========
[heap] Ensure finalization of incremental marking even if all allocations
come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

Now before expanding the heap we check if we are above the allocation limit
and the incremental marking needs to be finalized. If so we do not expand
the heap and force GC, which will finalize the incremental marking.
The check is performed for paged spaces and large-object space.

BUG=chromium:670675

Committed: https://crrev.com/fdc0aa0c97952e56686157b1023a8085885357b4
Cr-Commit-Position: refs/heads/master@{#41524}
==========

[commit-bot: I haz the power, 2016-12-06 14:06:49]

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