There is a long laundry list of reasons why the EROS architecture should not (Bershad would say can not) work. Most of these reasons turn out to be bunk, but they are backed by a lot of seemingly supportive data:

• Nobody has ever built a fast software-based capability system (KeyKOS, the EROS predecessor, came closest), and after the failure of the i432, most architects gave up on capability-based hardware systems. The key impediment in those systems seems to be that they had overly complicated memory translation semantics.

• EROS, in addition, is a dekernelized system. Bershad and Chen have argued that such systems have fundamentally higher cache overhead than monolithic systems. Actually, they made this argument about microkernels, but the logic and the data should apply to EROS as well.

• Then there is the Mach experience. Particularly worrisome there is the experience that the Mach group had with the external pager. Initially they moved all page fault handling into a user-level server. They eventually found that the performance of this was a problem and moved it back into the kernel.

  In EROS, it's not an option to move the external pager back into the kernel. In addition to externalizing page fault handling, EROS also externalizes storage allocation. The EROS kernel simply isn't in a position to allocate a page frame that can be used to grow the heap; it (the kernel) doesn't own the disk.

  In principle, then, there is some reason to worry that the EROS page fault handling logic will prove to be even more expensive than the Mach external pager. There are twice as many processes and twice as many IPCs involved.

All this being said, the data from L4 looks promising. L4 is several orders of magnitude faster than the best Mach implementation ever was. In previous work we showed (see The Measured Performance of a Fast Local IPC) that EROS can match L4's performance.