Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)

Wed Jan 3 12:44:00 GMT 2001

Ok,
I guess I can do without "hard space bounds".
Right now, I can live with the C malloc/free space bounds.
The problem is that now, GCJ is worst than C (It might
be more a psychological problem than a real one, but I'm
not willing to take the risk)
What would be ideal, I guess, is a mixed system: using whatever
collector is the faster most of the time, but if there is an
Out-Of-Heap conditions, stopping everybody and doing a complete,
slow, compacting & precise GC. I've look at the litterature, and
freeware stuff, but never found such a system. Most compacting
GC described are copying GC, and loosing half the memory is 
usually not an option in embedded systems. especially for system
without MMUs.
Cedric
"Boehm, Hans" wrote:
>> The problem here is that you really need a lot more than a precise GC to
> guarantee space bounds. You need the language or the implementation to
> define object reachability, or at least some bound on object reachability.
> I believe Java doesn't. And you need to ensure that you don't perform any
> optimizations that violate those space bounds, e.g. by extending the
> lifetime of a pointer to perform common subexpression elimination, or by
> delaying an assignment to a pointer that would release a large data
> structure. Does gcc do common subexpression elimination on calls to
> side-effect free functions that may allocate? It probably can move
> assignments to locals across function calls?
>> I believe there have actually been very few garbage-collected systems that
> guarantee hard space bounds. SML of NJ (Andrew Appel et al) went through a
> fair amount of work to guarantee that asymptotic space bounds were defined
> and preserved, but even they only guaranteed space usage up to a constant
> factor, which is less than what you need here. (Reasonable space bounds on
> malloc/free programs arguably aren't any easier, but that's a different
> story.)
>> Hans
>