Disable tests with WaitForPendingFinalizers in gcstress testing

[janvorli]

Some if not all tests from the Methodical suite that use GC.WaitForPendingFinalizers timeout due to the fact that a finalizer of Gen2GcCallback calls a callback that ends up creating another finalizable object that is ready to be finalized. Also a GC memory is allocated in that callback, which triggers the GC stress collection. So the finalization thread keeps finalizing objects on the queue forever and the GC.WaitForPendingFinalizers never exits.

This change disables all tests in the Methodical suite that wait for pending finalizers when running with GC stress enabled.

Closes #104062

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[janvorli]

/azp run runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Would @VSadov change #103738 be a better fix for this problem?

Trying to find every test that calls WaitForPendingFinalizers somewhere gets boring fast.

[VSadov]

I think #103738 is a better fix. Perhaps we should review and merge it.

I wanted to get it stress-green, at least on runtime stress, but we keep seeing stress issues not related to the PR.
The PR itself could be useful to deal with those as it makes things more robust and faster.

I also wanted to be able to run Libraries tests and that is mostly possible, but just like with runtime tests there are few tests that are sensitive to GC stress in some subtle ways (i.e. anything that checks for "reasonable" time spent for something...) and there are some tests (i.e. Dynamic stuff, RegularExpressions,..) that take ridiculously long even with more optimized stress approach.

The change allows to run many Libraries tests and thus is very useful for local investigations, but for lab runs we may need to come up with some filtering/excluding mechanism.

[cshung]

I am wondering if we could provide a better API for this purpose, something like GC.WaitForCollection(weak reference to obj) or GC.OnCollection(weak reference to object, Action callback);?

Other than preventing the infinitely locked situation under GCStress, this API will also:

• Make the intent of the tests clear (i.e. what exactly are we waiting for)
• Potentially allow a faster response time (e.g. WeakRef might get null out early after background mark, and there is no need to wait until all finalizer completes), and
• Hopefully reduce the need for using finalizers, you can still use GC to manage life time, but not unnecessarily lengthening object lifetime through finalizer.

It is just a rough idea, I don't know how feasible that would be yet.

[jkotas]

I am wondering if we could provide a better API for this purpose, something like GC.WaitForCollection(weak reference to obj) or GC.OnCollection(weak reference to object, Action callback);?

This looks very much like phantom references (that can be used as finalizer replacement among other things). If we wanted to expose them, I expect that it would be a new type of GC handle at the lowest level.

[janvorli]

I am fine fixing the problem itself instead of disabling tests like this. I just made it as a quick way to make the gcstress legs green again.

[janvorli]

Closing this PR as #103738 has implemented a fix for the issue.