Definitely agree with you that abstraction matters. I use C as an example because it's the canonical way in which we as developers can reasonably converse about directly dealing with the machine. C is still important and will continue to be important because it's arguably the best abstraction we have to write code directly against the machine. GC and STM would be orthogonal to the purpose of C.

It's really sort of pointless to argue what's possible in environments lacking real, unsafe pointers, because the whole idea with mmap()'d I/O is that it lets apps access files as if they are a region of memory. Java wraps up the behavior in FileChannel, and most other platforms have a way to access mmap() in some fashion, albeit the practical use cases are vanishingly small. In C, it's done mostly for squeezing out bits of extra performance by shrinking memory requirements/allocation cost and avoiding copies. Much of the safety mechanisms used by VM environments invalidate or make unavailable the shortcuts that are used in tandem with mapped I/O to achieve higher performance.

In the end, it's all still triggering the virtual memory interrupt that will load the page from disk if it's not in RAM, and the kernel is still going to suspend the calling thread while it's happening. No way around that. Alleviating this through thread pools would just re-introduce the issues of inter-thread locking and context switch overhead, and present an additional bottleneck; in the end just piling on extra complexity. I don't see that as a net win at all.

While the post has some great information on mapped I/O, it seems as if the author is dogmatic about the use of mapped I/O and is trying to find a way to use this hammer in a situation where it might be inappropriate.

EDIT: To the author who replied: awesome, awesome. Ultimately this is great stuff to talk about and these types of posts are what HN should really be about, even though it's turned into startup TMZ.