cannot build libjava/gnu/gcj/xlib/natClip.cc

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@albatross.co.nz> writes:

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.  Anyway, it is unlikely to happen since
it is a lot of work.

Bryce> This is a PITA and also inefficient, especially given that we
Bryce> need to worry about program code overriding the object and
Bryce> registering its own finalizer. _Jv_AllocBytes is just so much
Bryce> more convenient.

True.  However, user finalizers should be calling super.finalize().
If they don't then that is a bug in that code, and not really our
problem.

Tom