Patched `rts` heap reservation logic on Android:
* Need for patch
- There seems to be a bug on Android. Sometimes simple commands like `ghc --help` usage 90% - 100% cpu and hangs.
- It doesn't happen every time, but ~25% of the times (at least in my
testing).
* Cause of the bug
- The function `osReserveHeapMemory` tries to allocate virtual space starting
from `0x4200000000`. The allocated space has to start at an address >= this address.
- If the kernel doesn't allocate inside this space, it keeps on repeating the
`mmap` call with increasing starting point.
- Now, on Android the kernel sometimes return an address above (as in counting)
this `hint` address. It repeatedly returns the same address for subsequent calls.
- Thus, an infinite loop occurs.
References:
- 383be28ffd/rts/posix/OSMem.c (L461)
- https://github.com/termux/termux-packages/pull/22991#issuecomment-2759137291
* Solution (proposed by Robert Kirkman):
- It introduces a new helper function `osTryReserveHeapMemoryRecursive`.
This transforms the heap reservation logic into a recursive one.
- `osTryReserveHeapMemory()` is run multiple times without unmapping the
undesired addresses. Thus, forcing the kernel to map subsequent calls of
`mmap` to a new, unique address until an address above the `0x4200000000`
mark is obtained.
- After which each recursive call unmaps its undesired address before returning
the desired address (in order from last mapped to first mapped).
References:
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14164
- https://github.com/termux/termux-packages/pull/22991#issuecomment-2761325484
Co-authored-by: Robert Kirkman <rkirkman@termux.dev>
Signed-off-by: Aditya Alok <alok@termux.dev>
