From owner-freebsd-hackers Tue Jul 13 15:34: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B01DE15088 for ; Tue, 13 Jul 1999 15:34:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81393; Tue, 13 Jul 1999 15:33:40 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:33:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132233.PAA81393@apollo.backplane.com> To: "Neil A. Carson" Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132130.OAA24167@lestat.nas.nasa.gov> <378BB9DB.F1CE6978@causality.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Jason Thorpe wrote: :> :> On Tue, 13 Jul 1999 14:14:52 -0700 (PDT) :> Matthew Dillon 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message