Doug Hoffman <
glid...@gmail.com> writes:
> I have spent some time with a (Anton Ertl's) GC package... In short I
> was pleasantly surprised at how well the GC works and have softened my
> personal opinion of the GC approach.
Oh my, I had forgotten where the documentation for Anton's package was,
so I typed "Ertl garbage collection" into a search engine, and the first
hit led to this:
http://www.3000toys.com/catalog/item_detail.aspx?itemfind=ERTL39464
> I have written a "minimalist" objects extension. It ... is pretty
> small (about 30 lins of code). In order to use GC with it one must
> first load the GC code which is about 5 times the size of the objects
> package. This doesn't bother me but some might not like it.
I think in small or memory-constrained systems, there are few enough
heap objects that manually managing them isn't so bad; and at the same
time, the GC approach has enough memory cost that you don't want to use
it anyway. (The memory used by the GC itself is quite small, but
between GC runs there will be piled-up dead objects occupying memory
while they wait for collection). In larger systems where GC helps more,
150 lines of GC code doesn't seem like a big deal if the programmer
doesn't have to think about it too much after loading it.
> Perhaps if GC were part of the ANS standard and most mainstream Forths
> had it already loaded in the kernel or whatever this would not cause
> anyone heartache.
That would be interesting. I'm not privacy to the workings of the
standardization committee so I can only guess at the sorts of
conniptions that might greet such a proposal ;-).
> - One must manually take care of a "GC resize". Not a huge deal, but
> it does slow things down. Not sure how to write dynamically resizable
> entities without a resize function.
You mean you want something like an extensible array inside an object?
Yeah, if it has to stay contiguous then you have to allocate a new
larger block and copy the data. Alternatively you could allocate in
segments (or a tree structure) and have your lookup function navigate
appropriately.
> - 0 ALLOC will crash if done more than once without resizing
That sounds like a bug to me, but I haven't used the package yet.
> - Often, when "cleaning up" data such as when closing a file, at the
> same time one uses FREE one also might be resetting variables to 0 or
> some other initial state.
Some GC's allow attaching finalization code to objects, that gets called
when the object is collected, but I think that approach wouldn't work
with conservative GC, and for resources like file descriptors is too
leaky even with precise GC. So yeah, GC helps with memory management
but other sorts of resources still need manual attention ;).
> Thanks for the thoughtful explanations. I will consider GC in future
> projects where I see the need and a good fit.
Excellent, the next step is to get you using Lisp ;-).