This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: cannot build libjava/gnu/gcj/xlib/natClip.cc
- To: Bryce McKinlay <bryce at albatross dot co dot nz>
- Subject: Re: cannot build libjava/gnu/gcj/xlib/natClip.cc
- From: Tom Tromey <tromey at redhat dot com>
- Date: 03 Jan 2001 12:24:48 -0700
- Cc: Per Bothner <per at bothner dot com>, java-discuss at sources dot redhat dot com
- References: <m21yup9kpj.fsf@kelso.bothner.com> <3A4FC13C.755758CB@albatross.co.nz> <m2r92o83fz.fsf@kelso.bothner.com> <3A512F26.5DAD2970@albatross.co.nz> <m2g0j28woq.fsf@kelso.bothner.com> <3A528765.A29F5BDB@albatross.co.nz>
- Reply-To: tromey at redhat dot com
>>>>> "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