class gc

[Jeff Sturm]

hmm... what objects besides classes can gcj allocate statically?  String
literals?  Static/final members maybe?

Per Bothner wrote:
> 
> > 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).

-- 
Jeff Sturm
jsturm@sigma6.com