Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!EDDIE.MIT.EDU!think!mac%rhea
From: think!mac%rhea@EDDIE.MIT.EDU (Mike McNamara)
Newsgroups: gnu.emacs
Subject: Re: Why Gnu Emacs doesn't release memory
Message-ID: <8910301930.AA26327@rhea.ardent.com>
Date: 30 Oct 89 19:29:48 GMT
Sender: daemon@tut.cis.ohio-state.edu
Reply-To: mac@ardent.com (Michael McNamara)
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 45


In article <8910261557.AA02573@sn1987a.compass.com> 
	compass!worley@EDDIE.MIT.EDU (Dale Worley) writes:

>  The traditional solution to such problems is called 'compactification'
>  -- moving all in-use data areas into a compact mass at the low end of
>  the data area, and then deallocating the huge free area left at the
>  high end.  To do this successfully requires that all pointers to any
>  data area be altered to point to the new addresses, which (despite
>  some earlier speculations of mine) requires much careful design and is
>  very error-prone.

	Could you just add one level of indirection to the memory
allocation scheme? 

        ie. define a new malloc to be
      char ** gc_malloc(unsigned int);
	instead of
      char * malloc(unsigned int);
	You also need a 
      gc_lock(char**); and 
      gc_unlock(char**),
        which allow modules to temporarily gain protection for a
        dereferenced pointer.  [Perhaps this is what you mean by
        careful design and error prone.]

	You slowly migrate the potentially large memory allocators to
	this scheme.

	I have programmed a number of PC's which used the above scheme
	to manage memory.

	Then when compactifing, you simply deal with those of your
	internal list of char*s which are not currently gc_lock'ed.

	At the expense of an additional dereference for every pointer
	usage (non trivial, yes, but 32MHz is pretty fast..), this allows
	simple, save memory compactification.

>  
>  Dale Worley		Compass, Inc.			worley@compass.com
>  --

   Michael McNamara 	(St)ardent, Inc. 		mac@ardent.com
   --