test(bare-metal): two allocator arms, and the on-chip heap budget

[Ttimmahlax]

One firmware source, the allocator picked by a cargo feature, so the only
difference between the builds is which allocator serves the codec.

The budget, which is the number a firmware author actually needs

workload	peak heap	smallest heap that round-trips
L1 only	112,468 B	112 KiB (110 KiB fails)
L1 + L3 + L5	175,832 B	176 KiB (172 KiB fails)

The jump is DFast, not depth. L1 peaks at 112,468 and L3 at 175,832; L5 adds
nothing over L3. The second hash table DFast introduces costs about 62 KiB here,
buying 19.39x against L1's 17.65x on this corpus. A firmware that can live with
L1 saves a third of its heap. Everything is transient: current after a round
trip is 41,292 bytes, so this is a peak, not a resident cost.

The rusty_alloc arm does not work on this part

Not because of the codec:

	esp-alloc 0.11	rusty_alloc 2.0.5
round trip at 192 KiB	PASS	OOM on a 1,536 B allocation
round trip at 256 KiB	n/a	OOM on a 656 B allocation
320 KiB region	n/a	does not link, "Main stack is smaller than 8192 bytes"

Reduced to two lines with no zstd in them: in a 256 KiB region it serves
exactly one 64 KiB allocation, and the second fails with 192 KiB of the region
still free. Blocks of 32 KiB pack fine, four of them. The cliff is at the
segment size, and since RAM here is a fixed map, a larger region comes out of
.stack until the linker refuses.

Written up for the allocator's maintainers in
rusty_alloc/docs/plans/esp32-large-alloc-ceiling.md, framed as evidence plus a
hypothesis and two discriminating experiments rather than a diagnosis, since we
have not read their internals.

Static cost of the arm, both at 192 KiB, from the linked ELF: .bss +2,060,
.data −76, .stack −1,996, flash +7,536. The RAM columns sum to a constant
within 12 bytes, so the stack is what actually moves.

What is deliberately not claimed

No timing. Buffer placement alone moves compute kernels on this part by up to
20%, so an allocator throughput comparison from this rig would be measuring
placement, not the allocator.

An instrument bug, recorded because it nearly shipped as a finding

A sweep script wrote escaped backslashes into the source. Every build after it
failed, and three "identical peak" readings across L1/L3/L5 were the same
stale binary reflashed. The per-level numbers above are from a verified fresh
build, and the identical-looking result was the tell.

🤖 Generated with Claude Code