Re: flist -- "Killed" -- oom (*not* 1.8 related)

[Greg Minshall]

Robert, et al., thanks very much.

possibly mh-e could add something like a comma before integers.  i'll
ask and look.

on the more general issue, you all know a lot more about all of this
than me.  but ... :)

while actual bytes of memory on my laptop are semi-precious, addresses
in the address space are much less so.  here's somebody who uses mmap(2)
to allocate a huge chunk of address space, and then madvise(2) (a call i
think i've never used) to have that chunk backed by (lots and lots of)
zeroes.
----
https://robert.ocallahan.org/2016/06/managing-vast-sparse-memory-on-linux.html
----

i get the sense that nmh will only (after maybe zeroing the array, which
would be eliminated in this scenario!) access locations in the array
corresponding to actual "messages" found in the directory.  so, this
sparse array should stay sparse, right?

this wouldn't solve all problems -- places where the difference between
the largest and smallest "message" numbers is greater than the size of
the address space (+/-).

but, i wonder if it might help.  maybe combined with those places where
d_type is supported (and not "unknown") in directory entries.  at least
as a temporary fix?

and, if the mmap(2) call fails, that's maybe a way to provide a more
graceful termination than lots of sluggishness, then OOM.

cheers, Greg