Flaky GC-related tests with V8 12.2

[targos]

re. test-shadow-realm-gc-module and test-shadow-realm-gc, I think we should just skip them. Possible solution can be, use the more reliable checkIfCollectableByCounting() to check if the ShadowRealm instance in the main context can be collected, but I feel that would make the test invalid too (e.g. the native side can still be leaking even though the JS instances are collectable), so we might as well just skip and figure out a better way to test it later.

re. test-net-write-fully-async-hex-string, looks like it's related to --expose-gc again. I'd suggest that we just open an issue to track this and the shadow realm tests, and skip them for now. They are likely flaking due to incorrect assumptions in the tests broken by V8's new GC strategy, not real bugs.

Originally posted by @joyeecheung in #51362 (comment)

[joyeecheung]

Not sure if it's exactly related to test-net-write-fully-async-hex-string, but just something I notice: I discovered in my Oilpan migration prototypes that we may be under reporting externally-managed memory (#40786 (comment)), leading to poor GC performance.

[mhdawson]

@legendecas an FYI as I think you were working on shadow realm related stuff?

[jasnell]

@targos @joyeecheung ... can either of you update here on what is needed to address the flaky tests? For test-net-write-fully-async-hex-string, it's not clear from the discussion here what the issue might be or how the test might need to change and I've been unable to reproduce any failure locally.

[avivkeller]

FWIW I found that when I increased the --max-old-space-size flag in test-shadow-realm-gc.js from 20 to 25, it greatly reduced the failures (but not entirely removed them).

---

I also couldn't reproduce the test-net-write-fully-async-hex-string and test-shadow-realm-gc-module failures.

[targos]

I tried to enable the tests in #58232

Failure: https://github.com/nodejs/node/actions/runs/14905536948/job/41866906957?pr=58232

=== release test-shadow-realm-gc ===
Path: parallel/test-shadow-realm-gc
Error: --- stderr ---
node:events:485
      throw er; // Unhandled 'error' event
      ^

Error [ERR_WORKER_OUT_OF_MEMORY]: Worker terminated due to reaching memory limit: JS heap out of memory
    at [kOnExit] (node:internal/worker:314:26)
    at Worker.<computed>.onexit (node:internal/worker:230:20)
Emitted 'error' event on Worker instance at:
    at [kOnExit] (node:internal/worker:314:12)
    at Worker.<computed>.onexit (node:internal/worker:230:20) {
  code: 'ERR_WORKER_OUT_OF_MEMORY'
}

Node.js v25.0.0-pre
Command: out/Release/node --experimental-shadow-realm --max-old-space-size=20 --test-reporter=./test/common/test-error-reporter.js --test-reporter-destination=stdout /Users/runner/work/node/node/node/test/parallel/test-shadow-realm-gc.js

===
=== 1 tests failed
===

Failed tests:
out/Release/node --experimental-shadow-realm --max-old-space-size=20 --test-reporter=./test/common/test-error-reporter.js --test-reporter-destination=stdout /Users/runner/work/node/node/node/test/parallel/test-shadow-realm-gc.js

[joyeecheung]

I think the worker thread changes (or any changes in that direction) could make the tests more flaky, not less, because it would be less likely for any unblocking GC from any thread to block the main thread - performance wise that's a good thing, however, the tests generally count on GC to kick in and finish fast enough that the heap growth would not reach limit of the heap, they assume when the memory pressure is critical enough the whole world will stop and wait for GC before moving forward (they tried queuing foreground tasks in the event loop, which I don't think would do the trick now) which may not necessarily be a safe assumption especially for a very small heap limit value so that V8 doesn't have a lot of wiggle room to work with.

I think to make them more reliable it's between to just rewrite with something like checkIfCollectableByCounting and don't count on heap limits.