Re: Unrecovered memory leak thoughts.

Roger Pack wrote:
> If Ruby were to switch to a smarter GC style, at large landmarks might
> be a good time.
> Also one thought for the current implementation would be to maintain a
> single long freelist (every so often searching for unused heaps), as
> then when you sweep you wouldn't have to remark already freed objects.
>  Ok so I guess the only gain would be to not mark pages dirty that are
> free.  Not too great.  If you maintained an allocated_list as well
> then you could avoid traversing memory that is free.  Again a minimal
> gain. Sigh.
> 
> In other news the cause of the mem leak appears to be (this from  Marc
> de la Gueronniere) that scopes weren't realizing that they were the
> 'owners' of tables associated with themselves.
> The fix is posted there (well, kind of a fix--unofficially it seems to
> work).  Add
> ruby_scope->local_vars[-1] = 0;
> to parse.c and it seems to not leak.
> Take care.
> -Roger

As I noted earlier, there are probably thousands of CS papers on garbage 
collection. In the end the developer still has to manage memory, in the 
sense of knowing how much real RAM the application requires to function 
without thrashing, and in some cases, to restructure the code to do as 
much "static pre-allocation" as possible. What garbage collection does 
for you is eliminate the possibility of certain kinds of coding error 
and crashes.