GC performance - was Re: [gclist] GC topics

[Charles Fiterman]

> 
> "> We can allocate leaf objects. These land in separate pages from
> > non leaf objects. This makes scanning much faster. In generating
> > for YAFL you can tell leaf objects from non leaf objects and
> > generate the proper malloc.
> >
> It sounds interesting, but I do not really understand where it
> fits. It is true that since I can decide statically whether a
> class has leafs or not, I can allocate leaf objects separately from
> other objects pretty easily."
> 
> Separating non-pointer-containing objects is crucial for a nonmoving collector
> running in limited physical memory.  The collector does not need to see pages
> containing such objects.  In many environments they constitute the large
> majority of all allocated memory.  Thus this can greatly reduce the collector's
> VM footprint.  I don't know how to get the same benefit in a compacting or
> copying collector.

Our most extreme example is this. An interactive multimedia application took
80 Meg. Since we scan memory at 8 megs per second this meant a collection
cycle took 10 seconds. Totally out of the question. But 79 Meg were bitmaps,
making those leaf objects meant collection took 1/8 of a second. This was
easily buried in the idle time spent waiting for key clicks and mouse events.

A language that generates C can easily tell leaf from non leaf objects.