address space available to processes. this limit exists in most other
modern unix variants, and like most of them, our defaults are unlimited.
remove the old mmap / rlimit.datasize hack.
- adds the VMCMD_STACK flag to all the stack-creation vmcmd callers.
it is currently unused, but was added a few years ago.
- add a pair of new process size values to kinfo_proc2{}. one is the
total size of the process memory map, and the other is the total size
adjusted for unused stack space (since most processes have a lot of
this...)
- patch sh, and csh to notice RLIMIT_AS. (in some cases, the alias
RLIMIT_VMEM was already present and used if availble.)
- patch ps, top and systat to notice the new k_vm_vsize member of
kinfo_proc2{}.
- update irix, svr4, svr4_32, linux and osf1 emulations to support
this information. (freebsd could be done, but that it's best left
as part of the full-update of compat/freebsd.)
this addresses PR 7897. it also gives correct memory usage values,
which have never been entirely correct (since mmap), and have been
very incorrect since jemalloc() was enabled.
tested on i386 and sparc64, build tested on several other platforms.
thanks to many folks for feedback and testing but most espcially
chuq and yamt for critical suggestions that lead to this patch not
having a special ugliness i wasn't happy with anyway :-)
executable. Remove this so that different compiles can be binary
compared. rcsid's for all files are already embedded in the executable
so versions can be easily distinguished. (I didn't catch this on
previous passes because I did my builds on the same day.)
Note: there's a special rule for main.o in Makefile with a purpose I
can't actually discern -- I think it isn't needed, and I've flagged it
with a comment.
ht_new()... So actually rename it to condmkoptions to avoid confusion.
Reported build failure on amd64 (strange that I wouldn't get it on i386) on
current-users by Kurt Schreiner.
mrg