[wasm] Skip test on 'isolates' bot to avoid flaky OOM

Before running OOM on a wasm memory allocation, we trigger a GC, but
only in the isolate which allocates the new wasm memory. Hence if
multiple isolates are involved, we can run OOM anyway. This is a rare
case which did not cause trouble yet in the wild, so skip that test on
the 'isolates' bot for now.

R=ahaas@chromium.org

Bug: v8:9405
Change-Id: Ieb29a62e85db115320ae269e89d3e1fc451fd915
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1685793
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62505}

src/wasm/wasm-memory.cc

@@ -40,6 +40,9 @@ bool RunWithGCAndRetry(const std::function<bool()>& fn, Heap* heap,
     *did_retry = true;
     if (trial == kAllocationRetries) return false;
     // Otherwise, collect garbage and retry.
+    // TODO(wasm): Since reservation limits are engine-wide, we should do an
+    // engine-wide GC here (i.e. trigger a GC in each isolate using the engine,
+    // and wait for them all to finish). See https://crbug.com/v8/9405.
     heap->MemoryPressureNotification(MemoryPressureLevel::kCritical, true);
   }
 }

test/mjsunit/mjsunit.status

@@ -782,6 +782,11 @@
   # Slow tests.
   'es6/typedarray-of': [PASS, SLOW],
   'regress/regress-crbug-854299': [PASS, SLOW],
+
+  # Runs flakily OOM because multiple isolates are involved which create many
+  # wasm memories each. Before running OOM on a wasm memory allocation we
+  # trigger a GC, but only in the isolate allocating the new memory.
+  'wasm/module-memory': [SKIP],
 }],  # 'isolates'
 
 ##############################################################################