At 10:01 AM +0900 2/24/02, Yohanes Santoso wrote:
>"Sean O'Dell" <sean / celsoft.com> writes:
>>  "Yohanes Santoso" <ysantoso / jenny-gnome.dyndns.org> wrote in message
>>  stack-based memory management, or even reference counting.
>
>reference counting has this tendency of not being able to perform
>complete cleanup if the objects has circular dependency.

Reference counting also tends to be more expensive than most other 
garbage collection methods. The cost is amortized across lots of 
operations, but it adds up.

>  > memory available.  When that happens, I want it to shrink back up
>>  immediately after the process is finished.  But I don't want to limit my
>                         ^^^^^^^
>The OS will automatically clean up any finished process. Did you mean
>function? If so, then you're describing the behaviour of stack-based
>MM language like Perl.

Perl 5's not really a stack-based MM language. It's fully reference 
counted. (And thus suffers from the same issues as any other 
refcounted language) Yeah it will eat up memory if you leave 
references to large data structures in global variables or variables 
that haven't gone out of scope, but GC has nothing to do with it--the 
variables are still considered live, so they shouldn't be cleaned out.

>  Even in Perl, there is a need to regularly
>restart the process to keep memory requirement to a minimum because
>Perl cannot free up memory allocated in the main function (you leave
>the main function iff you stop the process).

This is more because of some lingering memory leaks than anything 
else. Those are just bugs, and get stomped as they're identified. 
(The latest versions of perl are a lot better about this)
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan / sidhe.org                         have teddy bears and even
                                       teddy bears get drunk