harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject Re: GC Compatibility (was: Re: State of the World)
Date Mon, 16 May 2005 08:04:18 GMT
>>>>> "Steven" == Steven Augart <saugart@yahoo.com> writes:

Steven> What really quashed the idea was the issue of garbage
Steven> collection -- GCC is not designed to pass type information
Steven> down to the lower levels of the compiler, so GCJ doesn't build
Steven> a "gc map", which you need in order to be use any GC other
Steven> than a Boehm-style conservative non-copying collector.  In
Steven> other words, GCJ is restricted to using a garbage collection
Steven> that looks for any bit patterns in the data that might be
Steven> pointers, and it has to assume that all of them are pointers.

As Anthony said, this was once done for Modula-3, but never integrated
into the main GCC sources.  FWIW, gcj only requires a conservative
scan of the stack, not the heap; it would be possible, with some less
invasive compiler changes (I think), to allow for a mostly-copying
collector.  I'm not up on the literature, maybe those aren't cool any
more.

Probably it would be less effort -- though correspondingly less
elegant -- to just make JikesRVM use a conservative GC and make calls
to the same functions that libgcj uess.  Usually this just means
disabling things.

... But once you do this you run into all the other reasons binary
interoperability is hard; my looks into LLVM, ORP, and Kaffe all
failed due to disagreement over exception handling.

Tom

Mime
View raw message