Re: Compiler writers will love this language

ericmuttta@email.com (Eric) writes:


> mwotton@cse.unsw.edu.au (Mark Alexander Wotton) wrote
>> On 5 Jun 2003 23:22:01 -0400, Eric posted:
>> >
>> > I am having difficulty imagining a type which is implemented using
>> > pointers and ensures that null cant occur. This would imply that for a
>> > variable of such a type, memory would be allocated and then never
>> > released.
>>
>> Either that, or only released when all references to it have passed
>> out of scope. This is how many modern garbage-collected language
>> implementations work.
>
> This scheme (reference-counting) is used in VB6 for instance. VB7 (and
> every other .NET language?) uses generational, mark-and-sweep GC (hope
> that's the right term for it). When I read its description, it sounded
> like a rather elaborate scheme and one that would need a good deal of
> implementation effort. I prefer plain vanilla automatic
> reference-counting. Its deterministic (hence useful in real-time
> systems), simple to explain and understand, and a lot easier to
> implement and get right.


Incidentally, generalized garbage collectors (I don't know the right
term, either) have been in use for at least 20-30 years, and have been
very well studied. Personally, I use two garbage collected languages
every day (Smalltalk and Emacs Lisp) and I have used several others,
and I have yet to run into a GC implementation bug. They doen't seem
to be so hard to implement so long as you are *very* careful about
your invariants.


In fact, garbage collectors can be modular. The main requirement is
that the GC module is able to trace data structures through memory at
runtime, which typically requires extra run-time information tagged
onto both objects and stack frames. The simplest implementation of
this requires one word of overhead per object or frame, but there are
lots of tricks available for lowering this overhead. Like most other
parts of a compiler, people tinker and tune for some amount of time
and then force themselves to leave it alone and actually use the
thing. :)


Finally, please consider that reference counting collectors will
surprise the user when they fail, and will require weird tweaks by the
user when they do fail. A generalized garbage collector is much
nicer.


> I admit, reference-counting has its problems and I have been toying
> around with an idea for what I call "compile-time
> reference-counting". Basically, I am looking for a set of rules,
> that will allow the compiler to figure out when to release memory
> for an object, *without* having to allocate memory space for a
> reference counter value. Instead, using these rules, the compiler
> can analyse code at compile time and statically work out the
> life-time of an object. Its a bit wishy washy at the moment but if
> its at all possible, I will write a paper on it :)




Be sure to look up existing work. I'm certain that people have worked
on this kind of thing. Be aware that it won't work for everything;
for example, objects that are saved out into the heap will be awfully
hard to deal with automatically. But you can surely get rid of a lot
of the intermediate increments and decrements in the way you seem to
be thinking about.




Lex
[Garbage collectors don't go back 20 or 40 years, they go back at least as
far as early versions of Lisp around 1960. I think it's safe to say that
any new garbage collection trick someone comes up with is almost certain
to have been discovered and analyzed before. -John]

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