[gclist] why malloc/free instead of GC?

[Enrico Weigelt]

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 ?

> 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.

-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux ITS 
 Webhosting ab 5 EUR/Monat.          UUCP, rawIP und vieles mehr.

 phone:     +49 36207 519931         www:       http://www.metux.de/     
 fax:       +49 36207 519932         email:     contact@metux.de
 cellphone: +49 174 7066481	     smsgate:   sms.weigelt@metux.de
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/