This is the mail archive of the
mailing list for the Java project.
Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
> 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.