Re: Garbage collectable C

meissner@osf.org
Wed, 12 Aug 1992 16:12:45 GMT

          From comp.compilers

Related articles
Garbage Collection and Interactive Languages eifrig@beanworld.cs.jhu.edu (1992-08-04)
Re: Garbage collectable C chased@rbbb.Eng.Sun.COM (1992-08-10)
Re: Garbage Collection boehm@parc.xerox.com (1992-08-11)
Re: Garbage collectable C meissner@osf.org (1992-08-12)
| List of all articles for this month |

Newsgroups: comp.compilers
From: meissner@osf.org
Organization: Compilers Central
Date: Wed, 12 Aug 1992 16:12:45 GMT
References: 92-08-015 92-08-045
Keywords: C, storage, GC

Most of the replies that I have seen about garbage collectable C are ways
to force variables into the stack (including emacs' GCPRO macros). One
thought that I've had is to shadow the variables when they get modified.
Ie, if you have a variable foo that is local to the function, the
meta-compiler would create both 'foo' and 'shadow_foo' variables, where
'shadow_foo' is a structure that contain's foo's current value, and a
dynamic link to other shadowed structures in this or previous activation
frames. Whenever 'foo' is modified, you update 'shadow_foo' as well.
That way, to search for the live values, all you have to do is search the
shadow chain. Setjmps would be handled by having the setjmp calling
routines save the current shadow chain head pointer in a volatile
variable, and restoring it after longjmp yanks you back.


The cost of this method is to have the shadow chains on the stack, the
initial setup, and an extra store everytime the local variable gets
changed (and mods usually are rarer than accesses)
--
Michael Meissner email: meissner@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.