class gc

[Per Bothner]

> What other reasons are there to allocate class objects statically?

Time and space.  If you can allocate objects (Classes, arrays, other
objects) statically, you save startup time.  This not only the time
to allocate the object, but also to initialize it, since you can
initialize it statically.  This also saves you space, because otherwise
you have to allocate extra space for either code or a table containing
the data to initialize the object *from*.  This is especially
valuable for arrays.  I believe you also save time
when GC'ing, though I guess here we disagree.  Certainly in a copying
or mostly-copying collector there is never an issue of copying the
static objects.  There is no difference when following precise
pointers whether an object is statically allocated or on the heap;
the contents have the layout.  The only complication is when doing
a conservative scan, and determining if something is a possible
pointer.  So, validating a random pointer may be more complex,
but I don't see how it can make much difference.  If you make sure
to allocate all the statically allocated GC'able objects in their
own section, you just need to check one extra range (per shared library).

One question is what proportion of memory needs to be scanned
conservatively and what can be scan precisely.  Basically, we
only need to scan stacks conservativly.  In most applications
with non-trivial garbage, I would assume the stacks are a relatively
small percentage of the memory we need to scan.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner