This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]