[Vm-dev] Memory leaks

Phil (list) pbpublist at gmail.com
Thu Dec 31 20:29:02 UTC 2015


On Thu, 2015-12-31 at 08:14 -0800, KenD wrote:
>  
> On Thu, 31 Dec 2015 03:36:46 -0500
> "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > I was curious if the VM has any facilities to assist in tracking
> > down
> > memory leaks? (not in the VM itself, but rather in the image it is
> > running)  The scenario that comes to mind are object reference
> > loops
> > though there are likely others to consider as well.  Any pointers
> > are
> > appreciated.
> 
> Hi Phil,
> 
> It depends on what, specifically, you are doing.
> 
> There are tools in Caregory Tools-ReferenceFinder which I suspect
> would be of help.
> 

I've been using reference finder and weight explorer to do some
preliminary investigation but given the current size of this image
(250M) it's slow going with each search taking upwards of a minute and
running into OOM problems.  But if that's all there is, I'll keep going
down this path.
 
> In the limit, any deep memory bug is probably investigated in a VM
> simulator.  This type of bug in a released image is rare.  Typical
> images do not load the object-memory/vm simulator, but you can build
> a VMMaker image which has the code.
> 

At this stage I'm expecting to find that it's my code doing the leaking
into the image, and not a base image or VM bug.  My original thought
was that I had some orphaned reference loops floating around but ran
across a post that indicated that unrooted reference loops should not
be a problem for the VM to gc.  I've done all of the obvious things I
could think of to minimize rooted references including closing
workspaces, browsers, inspectors, terminated Smalltalk processes etc.
 Any ideas as to what other possible ways these objects could be
rooted?

> Note that this is for people with deep knowledge.  You have to
> understand how objects are represented in memory, Cog (JIT) vs non-
> Cog, Spur vs non-Spur,  StackInterpreter vs optimized, ...
> 

Hoping not to need to dive this deeply just yet.  (esp. for what
appears to be a user-space problem)

> Two article blogs discuss the deeper currents within the VM:
>  http://www.mirandabanda.org/cogblog/
>  https://clementbera.wordpress.com/author/clementbera/
> 
> Note that because of the Squeak/Pharo/Cuis community, you can safely
> ignore the VM and play happily in Smalltalk, so don't feel you have
> to dive into this level of operations unless you have the calling for
> it (i.e. you are walking alone and something reaches out from the
> earth, grabs your ankle, and down you go.  Hey, it happens!).
> 

I didn't start down this path out of curiosity ;-)  You can only ignore
it when it doesn't result in your image growing by an order of
magnitude larger than it should be and beginning to experience
performance issues as a result.  I could start from a new base image
but as this is code I want to productionize at some point, I'd expect
that whatever is going on right now will be a problem down the road so
I'd rather deal with it sooner rather than later.

> Cheers,
> -KenD

Phil


More information about the Vm-dev mailing list