From: Eric Hodel <drbrain@...7.net>
Date: 2007-10-04T11:20:57+09:00
Subject: Re: [ANN] dike-0.0.1 - a memory leak detector

On Oct 3, 2007, at 13:12 , Tomas Pospisek's Mailing Lists wrote:
> On Tue, 2 Oct 2007, Joel VanderWerf wrote:
>> Michal Suchanek wrote:
>>> On 28/09/2007, ara.t.howard <ara.t.howard@gmail.com> wrote:
>>>> On Sep 28, 2007, at 11:26 AM, Joel VanderWerf wrote:
>>>>> That looks very useful. I'm not sure "leak" is the term I
>>>>> would use, since the objects are reachable. Unused reachable
>>>>> objects can be just as much of a problem as unreachable  
>>>>> objects, of
>>>>> course.
>>>> agree.  we seem to be the minority though ;-(
>>> Are there any unreachable objects in Ruby? They should be collected
>>> and go away eventually. So what I am left with is a gigabyte of
>>> reachable objects ... time to optimize space I guess.
>>
>> Sure there are. Ruby's GC is conservative. If it sees a number on  
>> the stack that looks like the address of an object, it assumes  
>> that the number is a pointer (though it could be something else)  
>> and it marks the object, even though the object might not be  
>> reachable. That's expected behavior.
>
> It occurs to me: how does conservative GC prevent the heap from  
> filling up with false positive pointers over time? This would  
> represent a "fully automatic memory leak for long running  
> processes"...

You'd have to be very lucky.

The values on the stack would have to be properly aligned, as a ruby  
object is 20 bytes (32 bit), and would have to be a pointer to an  
object that was large in order to prevent garbage collection of a  
large structure.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars