This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: robustness vs. conservative GC
- To: fjh at cs dot mu dot oz dot au, lord at regexps dot com
- Subject: Re: robustness vs. conservative GC
- From: dewar at gnat dot com
- Date: Mon, 30 Jul 2001 15:04:27 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org
<< Any scheme for doing exact GC without cooperation from the compiler
back-end needs to store pointers in a known location on the stack, rather
than in registers, so that they can be updated when objects are moved.
This denies the back-end compiler freedom to put such pointers in
registers. Register allocation obviously has a big effect on performance.
>>
I don't accept that, and there are most certainly counter examples to
this claim (e.g. IBM mainframe SPITBOL). It is fine to have pointers in
registers, providing that you have sufficient information to track them
down, i.e. know where the register values are saved.
With regard to problems caused by optimizations, a tricky case is virtual
origins for arrays. This can be handled (see Steve Burov's thesis from
IIT, 1977, R. Dewar advisor for a scheme applicable to Alogol 68 - in
fact while you are at it, read all the Algol-68 literature on garbage
collection, which always assumed a type accurate model, and also had
to deal with thread safety). However, it is definitely tricky, and in
fact it is possible to do virtual origin stuff at the source level in
C that can mess up a conservative allocator -- sure sure, I know this
is not strictly legal C, but it is C that will in practice work over a
wide range of architectures, providing that you are not using conservative
GC.