[gclist] why malloc/free instead of GC?

Enrico Weigelt weigelt@metux.de
Tue, 18 Feb 2003 14:31:50 +0100

On Mon, Feb 17, 2003 at 08:37:00PM -0800, Boehm, Hans wrote:
> Note that this gives you an average object size of a little over 50KB, 
> and that the malloc/free version never touches the allocated memory.  
> Any garbage collector will lose against malloc/free under those conditions, 
> due to both the huge average object size, and the fact that collectors 
> generally like to initialize at least possible pointer fields within objects.

GCs can cause problems if you use really huge memory. If it has no type
information, it must scan through all memory chunks and look for pointers.
With type info (i.e. in oberon) it could become much faster. 
But there's still another problem: if your application holds many pages,
which aren't accessed for quite a long time, they're possibly swapped out, 
but each time the GC runs over the heap, they have to be swapped in again.

hmm, is there any way to avoid scanning over the whole heap each time ?

 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/