[gclist] why malloc/free instead of GC?

Igor Pechtchanski pechtcha@cs.nyu.edu
Tue, 18 Feb 2003 13:58:07 -0500 (EST)


On Tue, 18 Feb 2003, Enrico Weigelt wrote:

> On Tue, Feb 18, 2003 at 12:28:51PM -0500, Igor Pechtchanski wrote:
>
> <snip>
> > 1) those where the large heap size comes not from the amount of data
> > handled in any one transaction, but rather from the number of concurrent
> > transactions.  Since each transaction is (usually) a separate entity,
> > approaches like region-based GC or transaction-specific heaps might work
> > well there.
> This is tricky if there are references from one region to another.
> How to cope with this ?

Same way generational GC copes with it, i.e., through write barriers.
However, when I said "separate entities", I meant mostly "independent
heaps", in which case there won't be any cross-references.

> > 2) those actually handling massive amounts of data for each transaction
> > (such as search engines).  Such applications mostly do not have a lot of
> > simultaneous live data, just a large data stream.  Since the performance
> > of, say, copying GC is proportionate to the amount of live data, this
> > shouldn't affect performance.
> For applications with limited lifetimes of several entities (i.e. request),
> there's another quite interesting model. Look at the apache-2, they're
> using different pools for entities with different lifetimes
> (i.e. request vs. thread vs. global). This is a little bit like the
> unix process model, where the whole vm memory gets freed when the process
> has died. The problem with this model is to take care of not mixing up
> several pools.

That's largely the idea behind region-based allocation/GC.  I believe it
was introduced in Trishul Chilimbi's paper, but I'm sure people here will
correct me if I'm wrong.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune