From: deraadt@fsa.ca (Theo de Raadt) Subject: Re: Thought: compressed libc ? Date: Wed, 10 Mar 1993 00:24:36 GMT
In article <1mj6ejINNlhg@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
> In article <1993Feb25.155944.25246@sol.UVic.CA> pmacdona@sanjuan (Peter
> MacDonald) writes:
> >
> > What I have long wondered is, could the same type of thing be done in
> > the kernel? ie, a special null page could be maintained (virtually?)
> > and the calloc function could have a system call to let the kernel
> > manage allocation etc.
> >
> > This could allow handling of sparse arrays and data structures
> > efficiently. Any comments (except drop dead)?
> Many Unices already do this. There is a problem, though: What do you
> do if you malloc(50MB) and then modify ever page, and you don't
> actually have 50MB of VM? There are 3 usual choices:
> 1) Panic. (Seriously! Mach does this.)
> 2) Freeze the offending process. (This is really nasty unless you
> know what's happening and can kill something quickly.)
> 3) Kill something. (AIX 3 does this, but it does warn processes with
> SIGDANGER first. Something like a background FTP mirrorer or even a
> redundant server might choose to exit, freeing memory.)
4) Do what BSD does. preallocate swap. Use it as backing store. Now
you can only ever run out of memory on system calls. The original
malloc(50MB) would of course fail, but you don't get screwed later on.
Problem solved.
<tdr.