The SlotHistory sysvar is too big to deserialize on the stack, and too big for the default heap size (32kb). Solana supports up to 256KB of heap, but a custom heap implementation is needed, even if you request an increased heap size with the compute budget instruction, since the default global_allocator just uses the hard-coded 32kb.
Mango's custom heap implementation implements a bottom-up heap as opposed to the top-down heap implemented by solana_program::entrypoint:BumpAllocator. The issue with the top down approach is, if you initialize the standard BumpAllocator with a larger heap length, instructions that don't need the extra heap space will start out allocating outside of the default heap bounds unless they submit a request_heap_frame instruction. By allocating from bottom up, allocs start in the valid bounds and don't need to submit the ix unless they go over 32kb.
The SlotHistory sysvar is too big to deserialize on the stack, and too big for the default heap size (32kb). Solana supports up to 256KB of heap, but a custom heap implementation is needed, even if you request an increased heap size with the compute budget instruction, since the default global_allocator just uses the hard-coded 32kb.
Mango's custom heap implementation implements a bottom-up heap as opposed to the top-down heap implemented by
solana_program::entrypoint:BumpAllocator. The issue with the top down approach is, if you initialize the standard BumpAllocator with a larger heap length, instructions that don't need the extra heap space will start out allocating outside of the default heap bounds unless they submit a request_heap_frame instruction. By allocating from bottom up, allocs start in the valid bounds and don't need to submit the ix unless they go over 32kb.