Experimental.BlockResizeArray is destabilizing

[jackfoxy]

Description

As evidenced by the tests that cannot run in mono, and pending destabilizing tests in the experimental tests project, beware that this data structure can be destabilizing to your assembly.

I'm just opening this as a discussion thread.

[github-actions]

🤖 This is an automated response from Repo Assist.

Investigated the current state of BlockResizeArray and the destabilizing tests to give a clearer picture.

What's happening today

There are two groups of BlockResizeArray tests:

Group 1 – Performance benchmarks (guarded with #if MONO … #else … #endif, lines 40–173): These run normally on .NET (non-Mono). They allocate ~42 M elements per run and exist solely to compare throughput against ResizeArray and Array. They're not correctness tests, they just print timings. If CI is slow or memory-constrained these could time-out, but they don't "crash" anything.

Group 2 – FsCheck property tests (marked ptestPropertyWithConfig, lines 240–325): These are the destabilising ones, and they're correctly kept as pending (skipped). The root cause is the BlockResizeArray constructor:

let mutable arrays =
    Array.init initArraysCount (fun _ -> Array.zeroCreate<'T> blockSize)
// blockSize = 1 <<< 17 = 131 072

Every BlockResizeArray(int)() instance pre-allocates a 131 072-element backing array on construction. That's ~512 KB per instance. With config10k (10 000 iterations), FsCheck would need to construct ~10 000 instances, requiring roughly 5 GB of memory — enough to OOM a test host or trigger GC pressure that affects other tests running in the same process.

Additionally, FsCheck has no registered Arbitrary(BlockResizeArray(int)), so it would fall back to reflection-based construction, which could raise an exception during test-case generation rather than a clean test failure.

Enabling these tests safely

To enable the property tests without destabilising CI, we'd need:

1. A size-bounded custom generator — build BlockResizeArray(int) from a small int list (e.g. up to 1000 elements) so FsCheck never triggers a huge allocation:

   let braGen =
       gen {
           let! elems = Gen.listOf (Gen.choose(-1000, 1000))
           let bra = BlockResizeArray(int)()
           for e in elems do bra.Add e
           return bra
       }
   
   type BlockResizeArrayArb =
       static member BlockResizeArray() = Arb.fromGen braGen

2. A size-bounded configuration — config100 (100 tests) or config1k is sufficient; 10 000 is unnecessarily large for correctness testing.

3. Change ptestPropertyWithConfig → testPropertyWithConfig with the custom arb registered — similar to the fixes applied to SkewBinomialHeap and DList tests in PR [Repo Assist] fix: enable and fix experimental tests for issues #115 and #116 #240.

I'm happy to create a PR for this if it would be useful. The fix is low-risk and would give the property tests real coverage without endangering CI.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f