GC statistics (was Re: big project ported)

Wed Oct 27 10:31:00 GMT 1999

>> >>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:
>> Godmar> The other option, which is slower, but presumably still a lot
> Godmar> faster than the current state of affairs is to do what I did
> Godmar> for kaffe: create a bitmap for each class (ideally in the same
> Godmar> format so I don't have to recompute it for gcj classes:-) The
> Godmar> code is in kaffe/kaffevm/classMethod.c:resolveObjectFields; it
> Godmar> should translate nicely to libgcj.
>> What is the copyright on this code? I routinely *don't* look at other
> implementations. This sucks for cross-pollinization, but is good from
> a cleanroom perspective.

It's GPLed, copyright is owned by TVT to whom I assigned it as a
kaffe distributor.
I think I'll just violate the cleanroom by including the code at
the end of this mail. Later on, I'll sue you. No, I'm just kidding.
The code is rather straightforward anyway. 
+ Start with the gc layout of the superclass. 
 If it's Object, skip the Object header.
+ Loop through the possible memory addresses (alignment of void*).
 Loop through fields in parallel. 
 + If it's a reference, set the bit to 1.
 + Otherwise to 0.
 
The walk function is equally simple, basically in the one word case
while (layout) {
	if (layout < 0) mark(i)
	layout <<= 1;
	i++;
} 
and could probably be optimized by people who know how to code
efficient bit ops.
The reason I said it would translate nicely is because libgcj appears to
use almost the same data structures for fields and methods as kaffe does
(and for utf8s and for the constant pool and for classes too.)
Who knows, there may have been some blind cross-pollinization going on 
somewhere. Personally and honestly, I'd very much wish to continue it.
>> The Boehm collector has built-in support for bitmap-based marking;
> this is in the inner loop of the marker. That is what Boehm suggested
> we use. We can only use it for "small" classes (the bitmaps have a
> fixed maximum size), but I think most Java objects will fit. My plan
> is to add a new field to Class and compute the bitmap at class init
> time.

Yes, I know. I was wondering why you didn't use that---I thought
the reason was that you may have to handle other cases, such as
marking classloaders or thread objects etc. that Boehm would not cover.
(Recall that objects keep their classes and their loaders alive, but 
they don't have a pointer to them in the struct. [*])
For most other cases, Boehm's bitmap should work just fine.
(Unless there's some penalty associated with having to create a new
allocation type per class.)
	- Godmar
[*] This leads me to ask a question about gcj's classloader support.
I understand that Kresten's interpreter allows for dynamically loaded
classes. My question is this:
Can I have any mixture of interpreted and compiled classes in my system?
In other words, can compiled classes refer to interpreted classes and
vice versa? Or is it such that interpreted classes can only refer to
compiled classes, but not the other way around?