class gc

[Godmar Back]

 Per,

> 
> > I'm not sure how adding a flag to the class would help since I do not
> > know whether a given reference actually points to a java.lang.Class object.
> 
> I don't remember the details, but the Boehm collector has a way to
> register objects with the GC.  So what you do is register all the
> statically allocated Classes with the GC on start-up.

Registering objects is a solution, but it would require to lookup
whether an object is registered at mark time: this would incur exactly
the costs I'd like to avoid.  Mostly likely, it would be more expensive
than using the already existing mechanism like you do now.

> 
> Actually, I don't see any need to register a Class with the GC; what we
> really need to do is register any static reference fields as global roots.
> 
> This is for statically-allocated Classes;  dynamically allocated
> classes are of course allocated by the GC.

I don't understand how these two paragraphs relate to the issue I've 
been describing.

> 
> As I said, I don't know the specifics, but this is a well understood
> problem.
> 

Maybe I should have phrased my position more clearly:
I would like it if you made all classes dynamic, because in the long
and short run it makes walking and marking easier and more efficient.
I would like to convince you that that's not only true for kaffe, but
most likely for libjava as well, if you are to have dynamically 
allocated classes and class gc.  The indirection penalty associated 
with an additional pointer access, on the other hand, seems rather 
small.

What other reasons are there to allocate class objects statically?
Is it initialization order or something like that?

	- Godmar