Implement reserveAllocationSpace for SectionMemoryManager

[MikaelSmith]

Implements reserveAllocationSpace and provides an option to enable needsToReserveAllocationSpace for large-memory environments with AArch64.

The AArch64 ABI has restrictions on the distance between TEXT and GOT sections as the instructions to reference them are limited to 2 or 4GB. Allocating sections in multiple blocks can result in distances greater than that on systems with lots of memory. In those environments several projects using SectionMemoryManager with MCJIT have run across assertion failures for the R_AARCH64_ADR_PREL_PG_HI21 instruction as it attempts to address across distances greater than 2GB (an int32).

Fixes #71963 by allocating all sections in a single contiguous memory allocation, limiting the distance required for instruction offsets similar to how pre-compiled binaries would be loaded into memory.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[MikaelSmith]

I have concerns about this and line 46:

uintptr_t RequiredSize = Alignment * ((Size + Alignment - 1) / Alignment + 1);

That calculation buffers by 1 Alignment, to ensure we always reserve enough space to align on address. It's inefficient, but not terribly.

If this sums up many calls to allocateCodeSection/allocateDataSection, does the caller also sum appropriately to cover those buffers?

[gmarkall]

I've tested a fairly similar change (based off these changes) in numba/llvmlite#1009 and the only issue I came across was that the alignment for the code segment requested during reserving the allocation can be smaller than the alignment requested when allocating the code segment - this is because the alignment for the code segment at allocation time takes into account the alignment of the stub (from here).

The ultimate effect of this is that sometimes the preallocation can be too small for the later allocation if the code size is right up close to a boundary (a page size boundary?) - for example I saw a preallocation request for 16380 bytes with alignment 4 resulting in an actual preallocation of 16384 bytes, then a later code allocation for 16379 bytes with alignment 8, which ended up trying to use 16392 bytes, slightly larger than the preallocation, and failing.

I hacked around this by by increasing the code alignment to 8 if it was less than 8 (simply because that seems to be the biggest stub alignment potentially used across all targets) and that seemed to resolve the issue. Ideally I would have queried the stub alignment, but I don't think there's an easy way to do that from within an RTDyldMemoryManager.

Perhaps the most correct fix is for RuntimeDyldImpl::computeTotalAllocSize() to take the stub alignment into consideration when computing the code segment alignment?

[gmarkall]

Also, I should have said earlier: many thanks for all your efforts and the trouble you've gone to to put this together - it is certainly looking promising, from the perspective of Numba on AArch64 platforms!

[gmarkall]

Perhaps we should clear the FreeMem vectors before returning early here? Otherwise, we could reserve no space, but still have some free memory left over from a previous reservation, then end up using that to satisfy a later erroneous request instead of hitting the assert that fails when we try to allocate memory without having reserved it first.

[gmarkall]

Or, is this OK to return early without clearing free memory, on the same grounds that we reuse a previous contiguous block below if there's enough space in the existing reservation?

[MikaelSmith]

Erroneous requests would negate any benefits from using reserveAllocationSpace. And yes, if I removed this early return it would still return early when checking for sufficient existing free space to satisfy the whole request.

[gmarkall]

TODO: add tests to MCJITMemoryManagerTest

This is done now, I think? Or are you planning to add more tests?

[gmarkall]

Now that numba/llvmlite#1009 (which essentially implements the same changes made here, just inside llvmlite) is merged and an RC has been produced, I've received various reports that this fixes issues related to #71963 on both macOS and LinuxAArch64 systems, and no reports of adverse effects - so FWIW, my confidence in this patch being a good fix is quite high.