This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Summer of Code project discussion


On Wed, 2006-05-03 at 20:35 -0700, Mark Mitchell wrote:
> Laurynas Biveinis wrote:
> > 2006/5/3, Daniel Berlin <dberlin@dberlin.org>:
> > 
> >> The number of *host* systems we support that don't have mmap is
> >> approaching 0, if it is not there already :)
> > 
> > Uhm, at least DJGPP as a GCC host system is alive and does not support
> > mmap. But according to the following discussion, that's non-issue.
> 
> In the long run, I don't think we really want to be using garbage
> collection at all. 

+1

> My opinion is, in the long run, memory pools really are what we want --
> just not as many as we used to have.  In particular, we want one memory
> pool for global trees (global types, variables with static storage
> duration, functions), and one memory pool for the body of each function.
>  References would be allowed from the body of each function to the
> global pool, but the other direction should be strictly limited to one
> pointer from each function to its body.  (This allows you to read
> in/write out function bodies more easily.)

I've always been in favor of memory pools of this sort, with the
addition of subpools for memory intensive per-iteration sort of  things.

IE we have something like

do_foo (apr_pool_t *pool)
{
   apr_pool_t *subpool = apr_pool_create (pool);

	for (i = 0; i < 10000; i++)
	{
		  apr_pool_clear (subpool);
		  garbage_intensive_thing (subpool);
	}
}

The subpool are automatically destroyed when the parent pool dies, so we
rarely free them explicitly.

This is exactly what we do in subversion, and the only memory leaks we
ever have are where we needed a subpool but didn't have one.
usually owing to the fact that nobody realized something could need that
many iterations of a loop, call a function that many times, etc.

The thing that obstacks miss are this subpool notion.


BTW, for people looking for a good featureful implementation of pools,
take a look at the pools in APR (apache portable runtime).  It supports
things like subpools, cleanup functions that can be called on pool
death, etc,


--Dan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]