PolymorphicResolverAllocationTest.UnrelatedRegistryEntries_DoNotAllocateAClosurePerCandidate fails: 4917 bytes allocated vs 1024 budget — real allocation regression or noisy measurement on busy runner #6057

Activity

1. systemorph-com

   added

   bugSomething isn't workingSomething isn't working

   sev:MMedium - secondary path broken, or easy workaroundMedium - secondary path broken, or easy workaround

   feedback

   on Oct 3, 2026
2. rbuergi commented on Oct 8, 2026

   

   rbuergi

   on Oct 8, 2026

   Contributor

   More actions

   Closing: there is no allocation regression; the 4,917 bytes came from the measurement, and the measurement has since been fixed twice on main.

   Timeline

   • This failure was on run 37038369562 (2026-10-02). At that time the test read one allocation delta per resolution, with no warm-up of the measured path.
   • feat(settings): seven settings tabs are templates — fed grids and markdown (data-binding B3, part 2) #5947 (merged 2026-10-03, commit 54bfd7b) changed the reading to be taken only after the JIT has settled. It now takes the minimum over repeated samples, because tier-0 code allocates enumerators and closures that optimized code keeps on the stack.
   • test(alloc): settle resolution and traversal readings separately — the min-of-differences read a negative allocation #6157 (merged 2026-10-05, commit 51f6c8d) settles the resolution reading and the traversal reading separately and subtracts them once. Taking the minimum of per-sample differences had produced a negative "allocation" (small=-7,284 on run 37271740357), which inflated large - small.

   Measured on main f8bf80f (local, macOS arm64, Release with -warnaserror, --filter-class MeshWeaver.Messaging.Hub.Test.PolymorphicResolverAllocationTest):

   • As shipped, the test passes: Extra resolution allocation beyond registry traversal: 0 bytes for 512 unrelated types (small=7,792, large=7,792).
   • Negative control: I reintroduced the per-candidate closure in PolymorphicTypeInfoResolver.ComputeDerivedTypes (var alreadyAdded = derivedTypes.Any(d => d.DerivedType == derivedType);, which is the shape MessageService DrainLoop throws OutOfMemoryException during hub delivery (recurrence of #4824) #5555 removed). The test then fails: Expected 45056 to be less than 1024, with small=10,544, large=55,600. That is 88 B × 512 candidates, so the test still detects the defect it exists to catch. I reverted the control afterwards.
   • CI: I scanned the Test Results (shard N) annotations of every failed MeshWeaver Build and Test run created between 2026-10-05 21:57Z and 2026-10-08 (137 head SHAs). None of them names PolymorphicResolverAllocationTest.

   NOT established

   • My scan does not cover runs whose failed attempt was later re-run to green; their run conclusion is no longer failure.
   • It also does not cover the window from 2026-10-05 17:15Z, when test(alloc): settle resolution and traversal readings separately — the min-of-differences read a negative allocation #6157 merged, to 21:57Z.
   • I did not reproduce the original 4,917-byte reading on the pre-feat(settings): seven settings tabs are templates — fed grids and markdown (data-binding B3, part 2) #5947 test.
3. rbuergi

   closed this as completedon Oct 8, 2026