Re: in defense of GC

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>> I realize this might not be the beste example, since I just made it
>> up. But the idea is, that (string ref) is (by the compiler) translated
>> into a char* and that result := ... actually becomes a malloc() plus a
>> copying of memory. some_var := None would compile to explicit
>> deallocation (pointer is overwritten with null).
>
> I am not convinced you can avoid GC. Can the compiler insert the appropriate
> deallocation calls? How would it know the string is not in use somewhere else?

As I said -- not the best example perhaps. GC cannot be avoided for
the whole language but for a subset. Not a syntactic subset, a
semantic one, if you like (it's in that respect similar to
eleminiating if branches and loops). 

I admit my example is not good or at least not complete. The whole
disciplin is, AFAIK, called "compile time garbage collection" and
usuallay seems to require some support from the type system or an
annotation language which embeds proofs or hints to proofs that the
values are used in a certain way.

I'm not pushing that as something to come tomorrow. But I believe it
might be the long term future just to specialize single program parts
of a program written in the full language (which has all, including
GC) instead of embedding low level languages or writing -- god forbid
-- the whole program in a low level language only because a tiny part
of it must be optimized or provide some guarantees.

> So I see only that some sort of reference counting scheme can be implemented
> in the restricted case, but that is just GC all over again, and a poor one at
> that.

In my example, yes. If I don't say about the string reference that it
is 'unique'. I hear, the Mercury type system provides such constraints
which help the compiler to do compile time GC.

>> Similarily, I think, it might be possible to avoid malloc() if
>> everything is done in static or local buffers.
>
> I don't think so. Many algorithms have unbounded and unpredictable memory
> usage patterns. 

No, no, no! Not in the general case. You'll have to write the
algorithm accordingly and then the compiler (nudged by a compile time
directive) will try hard to implement your source w/o using GC.

The point being: If (only if) you can do it in Ada / C w/o GC you can
always write a ML+1 (let's call it like this) program that the
compiler can translate into an object file that doesn't need the GC.

Have I know expressed my vision better? This is all S-F AFAIK, but
there was at least 1 experimental ML translation system that had
something like this and the whole disciplin is called compile time
GC. Don't hold me responsible for my vagueness -- this is not my
current work. Except if you have access to a research grant, then
we'll be forthcoming with more detailed plans :-)). (Joking, but only
half).

> These could only be handled by viewing the (large?) static
> buffers as preallocated memory, and then one has the equivalent of malloc
> and/or GC all over again.

Or simply reserving them during OS load time as is indeed done in a
lot of embedded software. My vision after all was to make FP possible
in embedded systems or better: To provide a seamless environment of FP
in which a embeddable sublanguage exists. Unified testing frameworks
and tools and all this would be the ROI.

Regards -- Markus