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) |
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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.