Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to do garbage collection in C
Message-ID: <32963@ucbvax.BERKELEY.EDU>
Date: 3 Dec 89 04:02:32 GMT
References: <153@fornax.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 78

In article <153@fornax.UUCP> mcdonald@fornax.UUCP (Ken Mcdonald) writes:
>This brings up several problems, namely:  
>How to explicitly access C's stack;
This is easy: just do &localVariable

>how to differentiate pointers from other data; 
Don't bother to try. If a bit pattern represents a pointer into your
private heap, assume that it really is one.  (I.e., it represents an
address between the start and end of your private heap. It may have the
wrong alignment because it is looking _inside_ one of your objects,
instead of pointing to the beginning of it, so you'll need to search your
heap to see if it actually points to a real object.)

The number of false matches will be negligable, and you'll simplify all 
your algorithms.  Since you can't tell if it is really a pointer or just a
coincidence, you won't be able to move the object pointed to, because you
won't be able to change the pointer, in case the match was just a
coincidence.

Alternatively, instead of passing pointer as arguments, or storing them in
local variables, create a structure:

struct {
	long	flag1;
	Ptr	myPtr;
	long	flag2;
};
and initialize the flag longs to some distinctive pattern like 0xF0F0F0F0.
Where you would normally pass or store a pointer, pass one of these, and
always uses these structures for local variables.
Then you can search the stack for sequences of 96bytes that start and end
with four bytes of flag. You could still get coincidence matches, but now
the chances are much less likely, particularly if you clear the flag words
in the locals before you return, so they aren't just hanging around,
garbage on the stack.

If you want to garbage collect as an interrupt task (a complex business.)
don't forget the 68000 registers may point into your heap.

Remember, the Mac pushes mixes of shorts and longs on the stack, so you'll
need to consider each 16-bit chunk first as the high part of the 32-bit
word it starts, second as the low part of the 32-bit chunk it ends.


>how to determine when the end of the stack has been reached.  
At the beginning of the program do:
Ptr stackBase;
main(){
	int dontCare;
	stackBase = (Ptr) &dontCare;
}

This guarantees that the portion of the stack currently in use is between
&localVariable and stackBase. Remember that the stack grows toward low
memory.  stackBase is a bigger (unsigned) number that &localVariable.

Have you considered giving up and recasting your problem to use reference
counts?

I used to be a lisp programmer, and my C programs show that fact. I've
been programming the Mac for five years and written dozens of programs for
it, and I've never needed a garbage collector. The Mac memory manager has
always suited me just fine.  I did build a little package of debugging
routines that let me log each NewHandle with what NewHandle returned and
who called it, and let me delete from the log when DisposHandle() happens
and print a report of which routine is responsible for which undisposed
handle. By being careful to place and activate these routines, I catch my
storage leakage problems. If you deallocate all your temporaries, you
don't need a garbage collector, but much more important than that: Storage
leakage bugs are almost always symptoms of _other_ bugs. If a garbage
collector hid my storage leakage bugs, I'd produce lower quality code
because I would be less likely to find those other bugs.

> The mac is a detour in the inevitable march of mediocre computers.
> drs@bnlux0.bnl.gov (David R. Stampf)
--- David Phillip Oster          -master of the ad hoc odd hack. 
Arpa: oster@dewey.soe.berkeley.edu 
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu