class gc

Fri Feb 26 21:08:00 GMT 1999

>> > 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.
>
You may have marginal startup time savings. However, I would conjecture
that gc is done more frequently than allocating a class object.
Furthermore, I believe that it is not necessary to have full data 
templates lying around from which to initialize these objects; and the 
code you need to initialize such metadata can most likely be shared,
as in "x.dtable = &ClassClass" or some such.
I do see your point about potential space savings, though.
Still, your discussion about what part of memory must be scanned 
conservatively and what part can be scanned precisely is I think not 
what I'm trying to get across here.
I'm looking at heap objects which you should be able to walk precisely
*and* mark their outgoing references precisely. That is, not only should you 
know what their layout is (to walk them precisely), but you should also 
know that references contained in them point indeed to gc-allocated objects 
(to mark those objects precisely, without having to perform any checks.)
If you mix gc-allocated and non-gcallocated objects, you cannot do the
latter. That is, you'll always have to check before marking an object
whether it's indeed gc-allocated or not (as Tom said you currently do). 
This is the overhead I would like to avoid, and the simplest way to
avoid it is to make sure that they're all allocated by the gc.
A more complicated way is to reserve room to fake gc headers so that
the check would be cheap. The space cost of this approach would be
4-8 bytes per such object.
I agree that you also have potential savings in a copying or mostly
copying collector since statically allocated objects are never moved: 
however, most likely, you'll allocate your class objects in a space 
were you don't have to move them, or at most once --- considering the
lifetime of class objects.
	- Godmar