[tmyklebu]

> The purpose of swap is not running things out of it. The purpose is shoveling unused data out of memory. And for that it doesn't need to be particularly fast.

You can't detect a priori whether data is "unused." If you guess wrong a few times in a row, you get the familiar pattern where your Linux box is unresponsive to everything and needs to be bounced.

If you could detect whether data is rarely used, swap still isn't necessary. Applications can mmap() a file and use that region for "rarely used data" if such is known in advance.

Extraneous functions should be backed by the executable in the common case. In the JIT case, they probably won't be JITted anyway.

I still think the OOM killer is less intrusive than swapping to disk. It kills some, but not all, of the processes on the machine get killed. The system pretty reliably comes back to life in less time than it takes a human to diagnose the problem and bounce the system. As a bonus, no human needs to get involved.

[Dylan16807]

> Applications can mmap() a file and use that region for "rarely used data" if such is known in advance.

They could, but that's a lot like just making swap be manual.

> Extraneous functions should be backed by the executable in the common case.

I don't mean the code itself, I mean all the data it builds up for something that isn't needed.

[tmyklebu]

> They could, but that's a lot like just making swap be manual.

Sure. Isn't that a good thing? Rarely-used data can be swapped out to storage allocated for the purpose, as you desire, and too-large working sets don't have to hose the machine.

> I don't mean the code itself, I mean all the data it builds up for something that isn't needed.

I guess I don't often run programs that waste large amounts of memory for no reason. Either my working set fits or it's too large, and swap only matters if it's too large.

Is Java the typical beneficiary here?