You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Added AggressiveOptimization to methods involved in measuring allocations.
Warm up allocation measurement before taking actual measurement.
Isolated allocation measurement.
Changed some `RuntimeInformation` properties to static readonly fields.
Removed enable monitoring in Engine (GcStats handles it).
Removed `GC.Collect()` from allocation measurement.
Sleep thread to account for tiered jit in Core runtimes 3.0 to 6.0.
Updated MemoryDiagnoserTests.
Block finalizer thread during memory tests.
Disabled EventSource for integration tests.
if(RuntimeInformation.IsOldMono)// Monitoring is not available in Mono, see http://stackoverflow.com/questions/40234948/how-to-get-the-number-of-allocated-bytes-in-mono
// we have no tests for WASM and don't want to risk introducing a new bug (https://github.com/dotnet/BenchmarkDotNet/issues/2226)
142
145
if(RuntimeInformation.IsWasm)
143
146
returnnull;
144
147
145
-
// "This instance Int64 property returns the number of bytes that have been allocated by a specific
146
-
// AppDomain. The number is accurate as of the last garbage collection." - CLR via C#
147
-
// so we enforce GC.Collect here just to make sure we get accurate results
148
-
GC.Collect();
149
-
148
+
// Do NOT call GC.Collect() here, as it causes finalizers to run and possibly allocate. https://github.com/dotnet/runtime/issues/101536#issuecomment-2077533242
149
+
// Instead, we call it before we start the measurement in the Engine.
150
150
#if NET6_0_OR_GREATER
151
151
returnGC.GetTotalAllocatedBytes(precise:true);
152
152
#else
@@ -218,9 +218,7 @@ private static long CalculateAllocationQuantumSize()
0 commit comments