class gc

Mon Mar 1 10:43:00 GMT 1999

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