Comment by codedokode
3 days ago
What about an architecture, where there are pages and access permissions, but no translation (virtual address is always equal to physical)? fork() would become impossible, but Windows is fine without it anyway.
3 days ago
What about an architecture, where there are pages and access permissions, but no translation (virtual address is always equal to physical)? fork() would become impossible, but Windows is fine without it anyway.
You are describing a memory protection unit (MPU). Those are common in low-resource contexts that are too simple to afford a full memory management unit (MMU). The problem with scaling that up, especially in general-purpose environments with dynamic process creation, is fragmentation of the shared address space.
You need a contiguous chunk for whatever object you are allocating. Other allocations fragment the address space, so there might be adequate space in total, but no individual contiguous chunk is large enough. You need to move around the backing storage, but then that makes your linear addresses non-stable. You solve that by adding a indirection layer mapping your "address", which is really a key/ID, to the backing storage. At that point you are basically back to a MMU.
Or you run everything with a compacting GC.
Well, unless you are ok with excluding software written in many common programming languages from your platform, that's not really an option.
It may be ok for embedded systems, but those recently have been evolving on the opposite direction.
3 replies →
Implementing fork() without address translation is possible — it's just expensive.
In MacRelix (a POSIX-like environment for classic Mac OS), when a process calls fork(), the system allocates backup memory regions for it and its child. Whenever one of them is switched in after its counterpart was the last of the two to run, the old one's regions are backed up and the new one's regions restored.