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

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Per Bothner wrote:

> We should be using RawData for such fields in case we ever make
> a non-conserveative GC and option.  This would require making G++
> as well as Gcj GC-aware, so it is not likely to happen anytime soon.
> Still, as soon as somebody does implement a precise GC then all
> places that use regular Object fields to point to malloc'd data
> are likely to cause crashes, so need to be fixed.

The collector is mostly precise already, thanks to the bitmap marking descriptors etc. I don't see how making it completely precise (such that even data on the
stack and in registers were scanned precisely) could be achieved without significant runtime overhead in either the collector or the generated object code.
Bearing in mind that only words that point exactly to the start of a GC allocated object could be misinterpreted as pointers, I think the chances of falsely
detecting references are insignificant, even more so on a 64-bit environment. Even if they do occur, being on the stack they're not likely to stick around for
long. And, hey, in the unlikely event that it does happen, its not a catastrophe.

> Might as well use RawData now.
>

The problem with it, as you pointed out, is that if we need to associate native data with a particular object instance and we use malloc, we then also need to
register a finalizer to free the native data later. This is a PITA and also inefficient, especially given that we need to worry about program code overriding the
object and registering its own finalizer. _Jv_AllocBytes is just so much more convenient.

regards

  [ bryce ]