class gc

Fri Feb 26 18:09:00 GMT 1999

 Jon,
>> Typical collectors check an address for being within the heap before they
> mark it. All conservative collectors work this way since that's the criteria
> they use to determine whether or not a given 32-bit word is a reference or
> not. Statically allocated classes will not be within the heap range and will
> be ignored by existing conservative collectors. So far, every JVM
> implementation I've seen uses such a collector.
>
Let's be more concrete here: Kaffe's gc has two methods, gcMarkObject
and gcMarkAddress. The latter does what you describe (i.e. checking first).
The former does not and is hence faster. You want to use gcMarkObject
and not gcMarkAddress if you can help it, even if you have a fast strategy
for finding out whether an address is in your heap range (which may very
well be fragmented, btw)
> Now if you have a more precise collector which knows which words in
> memory are really [Ljava/lang/Class objects and explicitly walks those
> objects, you can handle it by either:
>> 	1) Adding a flag to the java/lang/Class object to indicate
> 	 which classes are statically allocated.
> 	2) Checking the java/lang/Class pointer to make sure it's
> 	 inside of the allocated heap range.
>> Either way, I don't see it as much of a problem...
>
I don't see how any of these suggestions would work.
The problem is not walking the class objects, the problem is marking
class objects when following references. These references may or may not 
refer to objects that were allocated on the heap. In most cases, they're not,
and if you can help it, you don't want to check every time, or at least
make the check as cheap as possible (cheaper than what Boehm's or Kaffe's
gc does to find out whether an address points to an object in the heap.)
One possible way that might work in Kaffe is to lay out your object
such that the 4 or 8 bytes before it are free in the data segment. 
For "real" heap objects, these bytes will be zero or contain a valid
pointer (because, for instance, they're used by a treadmill collector
to keep the object in a linked list). You could use a magic 0xffffffff to 
determine whether the object is indeed from the heap or not.
Another alternative may to only special-case those locations that can
actually contain pointers to class objects. These would be static and
non-static member variables of type Object or Class and arrays thereof.
Still, this may be tedious. I guess you could do it by using two bits
per variable, one saying whether it's a reference or not, and the second
saying whether it is guaranteed to be a reference to an object on the
heap or whether you'll have to check. It would make walking objects 
slower and more complex.
	- Godmar