In practice, it'd be quite different because with ASLR, the compiler records the locations of all address references in the binary, so the OS knows what to fix

In practice, it'd be quite different because with ASLR, the compiler records the locations of all address references in the binary, so the OS knows what to fix up. At runtime, though, C programs normally leave no indication in memory of what is a pointer and what is pure data; even if you changed the compiler to emit this and the allocator to track it, you'd have problems with fairly common constructions like custom allocators, unions where it may be nontrivial to determine which alternative is in use (especially since the data may actually be uninitialized), tagged pointers, hashes based on the pointer value, et cetera. Garbage collectors for C run into the same problems and forbid some of those constructions, but they can always fall back on not collecting an allocation if they're unsure whether a reference to it is a real pointer or just an integer with the same value. If you're actually relocating things, you can't risk accidentally changing the value of some integer. Honestly, I don't expect such a scheme to be implemented, considering how complicated (and limited) it would be. It sounds more realistic to implement a scheme that implements the full semantics even if at a severe performance cost, as suggested in the article, and expect ported Mill programs to stop using fork without exec for anything important.