This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: robustness vs. conservative GC


<<  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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]