Hi! Thank you for clarification.
I just had a glimpse at the 'Libc::Mem_alloc' code in the libc. It is not impossible but also not straight-forward to extend its interface with an 'alloc_at' method. Do you see a way around it by adjusting the 3rd-party code to not depend on a specific virtual address?
Go runtime try to use memory in some standard way - they just reserve (not commit) big address ranges of memory, Then try to map (commit) it by chunks and use for heap and other purposes.
In theory, in the comments Go runtime developers mention that some 64bit systems can’t implement reservation and make just plain allocation. So, I try to force this approach by reserving single big (544mb) memory range using Libc::alloc(). And fail in genode (hang in requesting response from parent for memory extension) - see my other messages to the list today. Probably I can continue moving in this direction - it seems for me like heavy-weight approach.
Idea to be able to alloc just range of memory and reserve it seems more promising. I use similar approach in Windows when I can allocate some virtual memory (without physical ones) and control page faults inside the range by committing faulted pages in exception handler (e.g. making transparent compression on the fly).