[Aldor-l] Garbage collector

[Pippijn van Steenhoven]

I seem not to have expressed myself clearly enough.

On Thu, Dec 20, 2007 at 10:01:08AM -0500, Jacques Carette wrote:
> Pippijn van Steenhoven wrote:
>> By the way, you said that some functions allocate lots of easily
>> reclaimable memory. 
> This is "conventional wisdom" for all (mostly) functional languages, from 
> LISP onwards, not a detailed observation of Aldor per se.

The allocations happen at compile time. The "conventional wisdom" you mention
regards the runtime behaviour of functional languages.

>> There is quite a lot of string duplication (as can
>> be seen in the call log) and FoamNew calls. 
> That, on the other hand, is hard data.  The string duplication calls is 
> something real to examine - it just might be that this is what is needed to 
> get non-mutable strings into Aldor!

Again, non-mutable strings within Aldor might need such behaviour but
compilation certainly doesn't.

> The FoamNew calls need to be 
> classified further (some are real, some are just for transient objects I 
> would guess).

I have seen one place where the objects are allocated on the stack and
returned by value. This place is in srcpos.c for all struct sposStack returns.
I don't think return by value is a good idea but it would definately help for
small objects where heap allocation would grind the GC.

> As far as having code free its own memory, I believe that this discussion
> http://lambda-the-ultimate.org/node/2552
> is relevant, and it basically concludes that if you have enough memory then 
> GC vs explicit memory management have similar performance profiles.

Provided the GC is fast.. which I will just assume is the case.

-- 
Pippijn van Steenhoven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://aldor.org/pipermail/aldor-l_aldor.org/attachments/20071224/36315338/attachment.bin