Use Monitor.Wait instead of ManualResetEventSlim.

Author: timcassell

src/BenchmarkDotNet/Engines/Engine.cs

@@ -336,26 +336,32 @@ public static bool TryGetSignal(string message, out HostSignal signal)
         // https://github.com/dotnet/runtime/issues/101536#issuecomment-2077647417
         private readonly struct FinalizerBlocker : IDisposable
         {
-            private readonly ManualResetEventSlim hangEvent;
+            private readonly object hangLock;
 
-            private FinalizerBlocker(ManualResetEventSlim hangEvent) => this.hangEvent = hangEvent;
+            private FinalizerBlocker(object hangLock) => this.hangLock = hangLock;
 
             private sealed class Impl
             {
-                private readonly ManualResetEventSlim hangEvent = new (false);
+                // ManualResetEvent(Slim) allocates when it is waited and yields the thread,
+                // so we use Monitor.Wait instead which does not allocate managed memory.
+                // This behavior is not documented, but was observed with the VS Profiler.
+                private readonly object hangLock = new ();
                 private readonly ManualResetEventSlim enteredFinalizerEvent = new (false);
 
                 ~Impl()
                 {
-                    enteredFinalizerEvent.Set();
-                    hangEvent.Wait();
+                    lock (hangLock)
+                    {
+                        enteredFinalizerEvent.Set();
+                        Monitor.Wait(hangLock);
+                    }
                 }
 
                 [MethodImpl(MethodImplOptions.NoInlining)]
-                internal static (ManualResetEventSlim hangEvent, ManualResetEventSlim enteredFinalizerEvent) CreateWeakly()
+                internal static (object hangLock, ManualResetEventSlim enteredFinalizerEvent) CreateWeakly()
                 {
                     var impl = new Impl();
-                    return (impl.hangEvent, impl.enteredFinalizerEvent);
+                    return (impl.hangLock, impl.enteredFinalizerEvent);
                 }
             }
 
@@ -365,17 +371,26 @@ internal static FinalizerBlocker MaybeStart()
                 {
                     return default;
                 }
-                var (hangEvent, enteredFinalizerEvent) = Impl.CreateWeakly();
+                var (hangLock, enteredFinalizerEvent) = Impl.CreateWeakly();
                 do
                 {
                     GC.Collect();
                     // Do NOT call GC.WaitForPendingFinalizers.
                 }
                 while (!enteredFinalizerEvent.IsSet);
-                return new FinalizerBlocker(hangEvent);
+                return new FinalizerBlocker(hangLock);
             }
 
-            public void Dispose() => hangEvent?.Set();
+            public void Dispose()
+            {
+                if (hangLock is not null)
+                {
+                    lock (hangLock)
+                    {
+                        Monitor.Pulse(hangLock);
+                    }
+                }
+            }
         }
     }
 }

tests/BenchmarkDotNet.IntegrationTests/MemoryDiagnoserTests.cs

@@ -234,9 +234,8 @@ public byte[] SixtyFourBytesArray()
             }
         }
 
-        [TheoryEnvSpecific("Full Framework cannot measure precisely enough for low invocation counts.", EnvRequirement.DotNetCoreOnly), MemberData(nameof(GetToolchains),
-            Skip = "Some random background allocations are occurring that we haven't been able to figure out, causing this test in particular to be flaky." +
-            " Other tests likely also suffer from it, but their high invocation counts successfully drown it out. #2562")]
+        [TheoryEnvSpecific("Full Framework cannot measure precisely enough for low invocation counts.", EnvRequirement.DotNetCoreOnly)]
+        [MemberData(nameof(GetToolchains))]
         [Trait(Constants.Category, Constants.BackwardCompatibilityCategory)]
         public void AllocationQuantumIsNotAnIssueForNetCore21Plus(IToolchain toolchain)
         {