I think this would be very useful in some compacting garbage collectors
even in non-reallocation case too. A heap of large objects could be
compacted by transitioning between two huge regions of address space by
moving the pages with mremap. It's simple enough to cope with an
unaligned head/tail using memcpy if allocations aren't page aligned.
Of course, garbage collectors would also benefit from the ability to
make use of mremap for reallocations just as allocators like jemalloc
and tcmalloc would.
If you're unable to build enough interest in it based on the use case
for it inside allocators like jemalloc/tcmalloc, then I would suggest
poking the developers of the GCs in v8, etc. about it to see if they
have any use case for this.
It may be worth considering a new restricted system call instead of
extending mremap. Since the primary use case is about moving pages from
one region to another existing region, I see the potential for it to be
done without an exclusive mmap_sem lock just like MADV_{DONTNEED,FREE}
and page faulting. This would give up the ability to grow in-place but
that only happens if virtual memory is being fragmented anyway. The
destination and source would also need to match.
Attachment:
signature.asc
Description: OpenPGP digital signature