[gclist] why malloc/free instead of GC?

[Arlie Davis]

Microsoft's CLR (.Net Framework) does a good job on "large" objects.
Objects above a certain threshold (20k, I believe) are allocated in a
traditional malloc/free heap, but their lifetime is still tracked
through GC.  Also, since the CLR has access to all type information, it
only scans memory locations that are known to be pointers.

This is an elegant solution, because it shows that object lifetime
(explicit free vs. GC) can be separated from allocation mechanism
(contiguous heap w/compaction vs. fragmentable heap).

The same approach could easily be adopted by other GC implementations.

Also, consider the example (brought up here) of an application which
must process a high volume of transactions, with a high degree of
consistency of time required per transaction.  Just because you use a
GC, doesn't mean you *always* allocate fresh objects for every
transaction.  You can still -- selectively -- use object pooling.  Many
large applications that are based on explicit-free gain performance by
pooling instances of objects.

The same can be applied to environments that use GCs.  Actually, since a
single reference to a small connected graph of objects will retain that
entire graph, it's easy to pool entire graphs, by just holding a single
reference.

The only risk you run is that some piece of code retains a reference to
one of the objects you build.  Of course, you'll have to design your
application around this.  But doing so may be much easier and safer than
abandoning the use of managed/GC heaps.

-- arlie


-----Original Message-----
From: owner-gclist@lists.iecc.com [mailto:owner-gclist@lists.iecc.com]
On Behalf Of Enrico Weigelt
Sent: Tuesday, February 18, 2003 8:32 AM
To: gclist@iecc.com
Subject: Re: [gclist] why malloc/free instead of GC?


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 ?

cu
-- 
---------------------------------------------------------------------
 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/