Gracefully deal with unrealistically large allocation sizes

[qinsoon]

When we request alloc with an unrealistically large allocation size (e.g. 2251799813685249 pages or 9 223 372 000 GB in the following example from GHC), this breaks our assumptions about virtual memory (how much virtual memory each space has, how we store VM map, etc). This causes all sorts of assertion failures.

We would at least fail gracefully with a clear error message. It would be better we use our out_of_memory hook to let the binding deal with it.

See the discussion on Zulip: https://mmtk.zulipchat.com/#narrow/stream/315620-Porting/topic/mmtk_alloc

The backtrace for reference:

#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737347598464) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140737347598464) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140737347598464, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff7c61476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff7c477f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x000000000094f907 in std::sys::unix::abort_internal () at library/std/src/sys/unix/mod.rs:350
#6  0x000000000094d0b2 in std::panicking::rust_panic () at library/std/src/panicking.rs:742
#7  0x000000000094cea7 in std::panicking::rust_panic_with_hook () at library/std/src/panicking.rs:710
#8  0x000000000094cba2 in std::panicking::begin_panic_handler::{closure#0} () at library/std/src/panicking.rs:577
#9  0x000000000094b62c in std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::{closure_env#0}, !> () at library/std/src/sys_common/backtrace.rs:137
#10 0x000000000094c8f2 in std::panicking::begin_panic_handler () at library/std/src/panicking.rs:575
#11 0x0000000000413543 in core::panicking::panic_fmt () at library/core/src/panicking.rs:64
#12 0x00000000004135dd in core::panicking::panic () at library/core/src/panicking.rs:114
#13 0x0000000000a105b1 in mmtk::util::heap::freelistpageresource::{impl#3}::alloc_pages<mmtk_ghc::GHCVM> (self=0x1195658, space_descriptor=..., reserved_pages=<optimized out>, required_pages=2251799813685249, tls=...)
    at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panicking.rs:386
#14 0x00000000009ef955 in mmtk::util::heap::pageresource::PageResource::get_new_pages<mmtk::util::heap::freelistpageresource::FreeListPageResource<mmtk_ghc::GHCVM>, mmtk_ghc::GHCVM> (self=0x2961f9, space_descriptor=..., reserved_pages=2251799813685249, 
    required_pages=2251799813685249, tls=...) at /home/junmingz/ghc/rts/mmtk/mmtk-core/src/util/heap/pageresource.rs:23
#15 mmtk::policy::space::Space::acquire<mmtk::policy::largeobjectspace::LargeObjectSpace<mmtk_ghc::GHCVM>, mmtk_ghc::GHCVM> (self=0x1195578, tls=..., pages=2251799813685249) at /home/junmingz/ghc/rts/mmtk/mmtk-core/src/policy/space.rs:89
#16 0x00000000009cb397 in mmtk::util::alloc::allocator::Allocator::alloc_slow_inline<mmtk::util::alloc::large_object_allocator::LargeObjectAllocator<mmtk_ghc::GHCVM>, mmtk_ghc::GHCVM> (self=0x11b8520, size=9223372036854775816, align=8, offset=<optimized out>)
    at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/core/src/sync/atomic.rs:3025
#17 0x00000000009cb1f0 in mmtk::util::alloc::large_object_allocator::{impl#0}::alloc<mmtk_ghc::GHCVM> (self=0x2961f9, size=2712057, align=6, offset=140737350687356) at /home/junmingz/ghc/rts/mmtk/mmtk-core/src/util/alloc/large_object_allocator.rs:38
#18 0x0000000000834140 in mmtk_ghc::api::mmtk_alloc (mutator=0x11b83d0, size=9223372036854775816, align=8, offset=0, semantics=4294941856) at src/api.rs:81
#19 0x00000000007eda9f in allocateMightFail (cap=0xf574c0 <MainCapability>, n=1152921504606846977) at rts/sm/Storage.c:1115
#20 0x00000000007fdb15 in stg_newByteArrayzh () at rts/PrimOps.cmm:118