Revert "Reland "heap: Force incremental marking in C++ only workloads""

This reverts commit 679c373e.

Reason for revert: DCHECK failures in post_job.cc when running Chromium gtests, blocking V8 roll into Chromium.
See https://ci.chromium.org/ui/p/chromium/builders/try/mac-rel/928210/overview for example failures/stacks.

Original change's description:
> Reland "heap: Force incremental marking in C++ only workloads"
>
> This is a reland of 4fde3328
>
> Another Blink-related test fix landed, see chromium:1300492.
>
> Original change's description:
> > heap: Force incremental marking in C++ only workloads
> >
> > ... when above a certain minimum threshold. This is to guard against
> > memory running away in scenarios where the JS heap is empty and
> > there's only high throughput C++ allocations that don't allow for a
> > memory reducer GC to kick in.
> >
> > This logic should be revisited after Oilpan's young generation
> > collector is implemented which may allow switching to a more efficient
> > shrinking strategy for initial heap setup.
> >
> > Bug: chromium:1029379, chromium:1300028, chromium:1300492
> > Change-Id: I93924fc2fe77d6226c29358d3afb1cc9d6fbf3b1
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3484319
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#79255}
>
> Bug: chromium:1029379, chromium:1300028, chromium:1300492
> Change-Id: Ida66e0c944094472b4856d5fecef2d199d29549b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3487991
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79281}

Bug: chromium:1029379, chromium:1300028, chromium:1300492
Change-Id: Ifbdcf996a91cbdb5cce3b07059c333a7f1a9444a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3491187
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79294}

src/heap/heap.cc

@@ -5538,28 +5538,9 @@ Heap::IncrementalMarkingLimit Heap::IncrementalMarkingLimitReached() {
         !old_generation_size_configured_ && gc_count_ == 0) {
       // At this point the embedder memory is above the activation
       // threshold. No GC happened so far and it's thus unlikely to get a
-      // configured heap any time soon.
-      //
-      // TODO(chromium:1029379): Revisit initial heap configuration when Oilpan
-      // run minor GCs as that would allow using a shrinking logic similar to
-      // V8.
-      if (global_memory_available) {
-        const size_t embedder_allocated_memory =
-            global_memory_available.value() - old_generation_space_available;
-        constexpr size_t kEmbedderMemoryThresholdToForceIncrementalGC =
-            32u * MB;
-        if (embedder_allocated_memory >
-            kEmbedderMemoryThresholdToForceIncrementalGC) {
-          // If we didn't get a garbage collection within allocating
-          // `kEmbedderMemoryThresholdToForceIncrementalGC` of memory this means
-          // that the embedder is still in high allocation rate. We cannot
-          // expect it to run idle soon but need to configure the heap somehow.
-          return IncrementalMarkingLimit::kHardLimit;
-        }
-      }
-      // Start a memory reducer in case the hard limit for embedder allocated
-      // memory has not been hit yet which will wait until the allocation rate
-      // is low to trigger garbage collection.
+      // configured heap any time soon. Start a memory reducer in this case
+      // which will wait until the allocation rate is low to trigger garbage
+      // collection.
       return IncrementalMarkingLimit::kFallbackForEmbedderLimit;
     }
     return IncrementalMarkingLimit::kNoLimit;