class gc

Sat Feb 27 01:14:00 GMT 1999

>>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:

Godmar> I'm looking at heap objects which you should be able to walk
Godmar> precisely *and* mark their outgoing references precisely.
Godmar> That is, not only should you know what their layout is (to
Godmar> walk them precisely), but you should also know that references
Godmar> contained in them point indeed to gc-allocated objects (to
Godmar> mark those objects precisely, without having to perform any
Godmar> checks.)
I imagine the reason Per and others are not swayed by this is that
they perceive marking an object to be relatively expensive. Adding
one more check just doesn't seem like a big deal.
And when your argument is presented in this way, I agree with them.
gcj's output isn't really tuned for extremely fast marking. Right now
our marking glue function weighs in at about 100 LOC. It fetches the
object's class and then uses information there to determine which bits
to feed to PUSH_CONTENTS.
The check for whether the object is on the heap is two comparisons.
Here is the macro we use:
 // We must check for plausibility ourselves.
 #define MAYBE_MARK(Obj, Top, Limit, Source, Exit) \
	 if ((ptr_t) (Obj) >= GC_least_plausible_heap_addr \
	 && (ptr_t) (Obj) <= GC_greatest_plausible_heap_addr) \
	 PUSH_CONTENTS (Obj, Top, Limit, Source, Exit)
(I don't remember why we do the check ourselves. Sigh.)
As a result I find it hard to believe that removing these two checks
would have a significant effect on performance. Of course, without
measuring it, I can't be certain.
But anyway, as a first step, it seems like it would be more worthwhile
to investigate changing gcj to allow more efficient marking in
general.
Anyway, I think the real argument to be made here is that statically
allocating objects complicates write barriers to an unacceptable
degree. I believe (again without measurement -- a bad habit) a write
barrier is much more performance sensitive than a mark function. If
the write barrier must do heap plausibility checks (for instance to
fetch the referenced object's color), performance will suffer.
But I don't even really believe this. The write barrier will be
intimate with the memory allocator, which means the compiler must be.
So on the happy day when we have write barriers, we can also change
the compiler to lay out preinitialized objects with the same sort of
header the allocator uses and the write barrier expects.
Godmar> True. But minimizing the frequency of this check brings a
Godmar> huge performance improvement, as I witnessed when I
Godmar> implemented precise heap walking for Kaffe.
I find this claim interesting. I know nothing about Kaffe's GC. Why
wasn't this check just noise in the mark function logic?
Tom