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.

▲

mike_hearn 3 days ago | parent [-]

Or you run everything with a compacting GC.

▲

marcosdumay 2 days ago | parent [-]

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.

▲

mike_hearn 2 days ago | parent [-]

Sure, but we're talking about a hypothetical architecture without memory mappings but with pages and permissions. Software compatibility was already tossed in the trash can at that point.

▲

Veserv a day ago | parent [-]

The proposal is more generic than that, it is throwing away translation of any kind. If all you do is replace virtual memory to physical memory translation with object ID to physical memory translation then you buy almost nothing in terms of access complexity.

That means there is no indirection between reference and the backing physical store. To change the backing memory you need to change the reference.

As you point out, within a program you can solve fragmentation by using a compacting GC. However, you will still suffer from cross-program fragmentation. You can not move the backing store of those programs without rewriting their references. You can not even page out those programs and reload them into new locations without rewriting all their references. You effectively need a global, shared, cross-program compacting GC to handle fragmentation; a hardware or kernel GC.

	▲	mike_hearn 13 hours ago \| parent [-]
		Yeah, I think single address space OS like Singularity would be the way to go there.