:Jason Thorpe wrote:
:> 
:> On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
:>  Matthew Dillon <dillon@apollo.backplane.com> wrote:
:> 
:>  >     If you don't have the disk necessary for a standard overcommit model to
:>  >     work, you definitely do not have the disk necessary for a non-overcommit
:>  >     model to work.
:
:> from userspace.  That way, my correctly written program can take appropriate
:> action (like, say, invoke its type-stable memory pool garbage collector, and
:> try again).
:> 
:> Right now, BSD doesn't do this, and that makes creating a truly reliable
:> system *very hard*.
:
:John Dyson changed NCOS (which runs on swapless systems) for a behaviour
:whereby memory was accounted much more strictly and monitored by a
:background process on the desktop. When the 'statistical conditions'
:(which take partially into account memory that could be reaped by the
:pagedaemon, etc) get to a 'yellow' state, the desktop monitor asks
:applications to close themselves. Especially with ref to JVMs etc, this
:took a very long time to get right.
:
:	Neil

    This is an excellent example of a solution.  Another example would be
    to implement your own memory management subsystem... that is, your own
    shared library which keeps track of memory allocations on a global
    basis.  I could do one in about an hour.  One simply mmap()'s a 4K
    shared page into every process running on the system and then keeps
    track of memory allocations on a process-by-process basis, summing it
    globally within the structure to get an idea about overall memory
    use.  The library can then perform garbage collection and notification
    when the total approaches the danger level and it can do it almost 
    entirely independantly of the kernel's own memory management & paging.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>