[heap] Do not delay mark-compact by doing scavenge.

This hack is causing false "last-resort" garbage collections.

When incremental marking is in progress and overshoots the limit,
our heuristics in the allocator request finishing the mark-compact
because V8 is in optimize-for-memory mode.

However, the mark-compact gets replaced by scavenger which leads to
retrying the allocation two times and eventually doing last resort GC
(which throws away all the marking info).

BUG=chromium:697119

Review-Url: https://codereview.chromium.org/2723003003
Cr-Commit-Position: refs/heads/master@{#43554}

src/heap/heap.cc

@@ -990,24 +990,6 @@ bool Heap::CollectGarbage(GarbageCollector collector,
     }
   }
 
-  if (collector == MARK_COMPACTOR && FLAG_incremental_marking &&
-      !ShouldFinalizeIncrementalMarking() && !ShouldAbortIncrementalMarking() &&
-      !incremental_marking()->IsStopped() &&
-      !incremental_marking()->should_hurry() &&
-      !incremental_marking()->NeedsFinalization() &&
-      !IsCloseToOutOfMemory(new_space_->Capacity())) {
-    if (!incremental_marking()->IsComplete() &&
-        !mark_compact_collector()->marking_deque()->IsEmpty() &&
-        !FLAG_gc_global) {
-      if (FLAG_trace_incremental_marking) {
-        isolate()->PrintWithTimestamp(
-            "[IncrementalMarking] Delaying MarkSweep.\n");
-      }
-      collector = YoungGenerationCollector();
-      collector_reason = "incremental marking delaying mark-sweep";
-    }
-  }
-
   bool next_gc_likely_to_collect_more = false;
   size_t committed_memory_before = 0;