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.

[RedYetiDev]

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.