I don't quite get how exactly they are avoiding memory fragmentation. In current architectures VM is flat and continuous, it is then mapped to physical addresses, which can be fragmented. If they are dropping VM all together, they must be mapping physicall memory directly in process address space (thats probably the reason why there is no shared libraries support in their architecture), but then whats going to happen if heap has to grow?

My understanding is that there's still VM, but it uses a separate buffer (on-chip memory map) containing a list of segments that map each part of the process' memory to a physical address (virt->physical offset + length), rather than a multi-tiered paging structure. The advantage is quick virtual -> physical address translation and less space used for them vs page tables, but the downside, as you point out, is what to do when a process exceeds it's initial heap or stack segment.

In this case, I think the Forwardcom solution is to add another entry in the memory map for the next 2*n bytes of heap space.

> In current architectures VM is flat and continuous

Looking at /proc/$PID/maps for firefox, it contains well over 100 noncontiguous map ranges. The address 0x11b000000000, for example, is not mapped to anything, but addresses above and below it are.

You can handle the heap growing by just allocating a new page for it somewhere in free memory. Your heap doesn't have to be contiguous.