Conservative/precise GC

[Godmar Back]

 Dave,

upfront: the interface has not been designed with moving collectors in mind.
Any changes/improvements are very welcome, as always preferably in the form
of patches.  

In the rest of this mail, I'm describing the current CVS version.
1.0b3 is distant past for me.

First, there's two groups of allocation types:
There's objects that are gcable (freed by gc) and those that are fixed
(explicitly freed by the user, for instance in a finalizer).

Gcable allocation types are:
	GC_ALLOC_JAVASTRING
	GC_ALLOC_NOWALK
	GC_ALLOC_NORMALOBJECT
	GC_ALLOC_PRIMARRAY
	GC_ALLOC_REFARRAY
	GC_ALLOC_CLASSOBJECT
	GC_ALLOC_FINALIZEOBJECT

Fixed types are:
	GC_ALLOC_BYTECODE
	GC_ALLOC_EXCEPTIONTABLE
	GC_ALLOC_JITCODE
	GC_ALLOC_STATICDATA
	...
	GC_ALLOC_FIXED
	...
	GC_ALLOC_THREADCTX
	GC_ALLOC_REF

See initCollector in gcFuncs.c

The fixed types are like your normal malloc/free, basically --- the only 
reason why there's multiple types is to keep statistics (try --verbosemem) 
of how much memory is used for what.

We didn't have to use kaffe's allocator for those; we could have used the
systems malloc/free, this, however, would have been at the cost of heap
fragmentation.  The way in which Jason changed the allocator works best
if the heap as seen by kaffe doesn't have many holes in it.

> 
> What exactly are the semantics of the GC_ALLOC_FIXED option to
> gc_malloc?  Is it a hint that the new object has no references to
> other objects (hence walkNull), or is it to tell a moving collector
> that the object shouldn't be moved?  Or is it something else?

Objects allocated with GC_ALLOC_FIXED (and the other fixed types, for that
matter) are explicitly freed by the user.  All of them currently have, but 
don't have to have empty walk functions.  We don't have an attribute that 
specifies whether an object is pinned down or not yet.

However, I could imagine that you may not want to go thru the trouble
of keeping exact information of the places where pointers to fixed objects
are stored; so I would guess that these objects won't be moved.

If this reduces the efficiency of your copying collector; then you should
look into allocating fixed and gcable objects from different locations.

> 
> On the same note, what exactly is the difference between
> GC_ALLOC_NORMAL and GC_NORMAL_OBJECT?  (As of kaffe-1.0.b3, the only
> mention of GC_ALLOC_NORMAL in the code is for the allocation of the
> UTF8 constant intern hash-table.)
> 
> I'm using Kaffe 1.0.b3 on Linux 2.0.30.
> 

GC_ALLOC_NORMAL is gone.
There's no such thing as GC_NORMAL_OBJECT:
    GC_ALLOC_NORMALOBJECT is an allocation type that allocates objects 
		without finalizers.
    GC_OBJECT_NORMAL is a finalizer type that means an empty or no
		finalizer.

I hope that helps.  Please ask more questions if things are still unclear.

I really think you should look at the recent CVS and not at 1.0b3; I'd
like to think that the new interface as changed since then --- while far 
from being complete --- makes a lot more sense than what was in 1.0b3.

	- Godmar