[gclist] why malloc/free instead of GC?

[Enrico Weigelt]

On Tue, Feb 18, 2003 at 12:32:03PM -0500, Arlie Davis wrote:

> 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 just like oberon does w/ all objects.

If we've got some type information, we could use three heaps for 
different kinds of objects:

a) strings (and other objects which contain no pointers)
b) typed objects (we only have to know where pointers lay around)
c) untyped objects (must be treatened as an array of pointers)

For these three types we use different methods for catching pointers.
 
a) there are have no pointers. nothing to do
b) we have to look on each pointer location defined by the pointer map.
c) simply scan the whole chunk as an pointer array (assume aligned ptrs?)

On Unix we can map memory almost everywhere we wana have it, 
so we could split up our address space into several huge ranges,
where our pools lay in. So we can decide very fast, which object 
type an pointer points to.

Now it is the task of upper level functions to decide, where to allocate
an new object from. By default we use c) if we dont know more about
the object (malloc() replacement).

> 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.
Yes, for example you have an very large number of the same objects,
you could easily allocate an big array and use an simple allcation map.
You should try not to use pointers to the elements of this array,
because the gc perhaps does not like it (in oberon this is forbidden
by the quite strict type system), but adress by an simple index.
(this could also save memory space)

hmm... i'm currently thinking about using page fault information 
for optimizing the GC process (branch cutting?). is there any chance ?

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/