stack wrote:
Is it feasible to use the paging machinery to remap the memory of a process?
There's some point where moving larger amounts of memory will be faster using remapping instead of memcpy. That point moves depending on how well you optimize each of those functions.
stack wrote:
Assuming the client code is tightly integrated with the OS, what do you think?
There are optimizations that may not be possible in the general case but significantly reduce overhead when they are possible. For example, you can get rid of most of the TLB flushing overhead when the client or the CPU is single-threaded. A client that's aware of these situations can dynamically choose whether to call memcpy or to call the OS to remap pages.
stack wrote:
Are there additional issues with moving code around this way (other than the obvious need to fix-up dangling pointers)?
Code is usually not designed to be moved at runtime. You can move it when you load it, but why not load it at your desired address in the first place?