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