From: Jeremy Kemper <jeremy@...>
Date: 2007-09-29T02:43:02+09:00
Subject: Re: [ANN] dike-0.0.1 - a memory leak detector

On 9/28/07, 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 ;-(
>
> > If you have Strings created in two places, are they reported
> > separately in the output? I assume so, but I couldn't tell from
> > your examples. If you're looking for trouble spots, it would be
> > useful to know not just that there were N strings floating around,
> > but that N1 of them were created on line L1, N2 on line L2, and so on.
> >
>
> yeah, that's *exactly* what it does.  of course some objects, like a
> = [], do not allow ruby hooks to track them so they just get reported
> under the general stacktrace of '[]', but at least they are reported.
>
> > Does this have much of a cost on performance? (It doesn't use
> > trace_func, does it?) I'd like to have something like this enabled
> > by default for long-running deployed processes, not just in debugging.
> >
>
> not really.  it addes hooks into Object#initialize and Class#new to
> make sure the creation is stored via caller.  the location is stored
> in a big hash with finalizers to remove entries (object_id =>
> stacktrace of creation).  no reporting is done unless you call
> Dike.finger which, with the rails hooks, is done after every
> request.  so i wouldn't say it has now performance hit, but it should
> be a lowish hit.
>
> i'd be very happy to get some feed back.  so far it's been very
> useful - i've been able to find several leaks in rails (i think)
> which i'm looking into now.  it found 5 leaks in my app and i was
> able to fix them easily in about 10 minutes, so that's nice.

ruby-prof includes a really nice object allocation profiler (with a
small patch to 1.8.x) that may help verify the results you're seeing.
It increments a live object count on allocation and decrements on
garbage collection and runs super-fast.

Best,
jeremy