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

[Cedric Berger]

> Bryce> The collector is mostly precise already, thanks to the bitmap
> Bryce> marking descriptors etc. I don't see how making it completely
> Bryce> precise (such that even data on the stack and in registers were
> Bryce> scanned precisely) could be achieved without significant
> Bryce> runtime overhead in either the collector or the generated
> Bryce> object code.
> 
> There's definitely an overhead.  I have a paper here describing work
> people (Rick Hudson, I think) did to make gcc emit tables so that
> precise, copying GC can work.  For some applications this overhead is
> attractive, though, I think.

Form embedded systems, a precise GC would often be a requirement.
(it was one of the main factor why we (unfortunately) cannot use GCJ
for our current project)

When you have 256K of RAM, and your device must run 24h/24, you
don't want to take any change to leak memory and run out of heap
because of a conservative GC mistake.

In embedded systems, predictability it the top requirement. And I 
don't see how to get predictable results without a precise GC.

Cedric