Re: [Java-gnome-developer] Pixbuf memory leak

[Andrew C. <an...@op...>]

On Wed, 2011-10-19 at 18:01 +0100, William Temperley wrote:
>  I wonder if anyone has a
> quick and dirty workaround for freeing up this memory? I'm doing a
> production run of approximately 6000 maps for a website, which grinds
> to a halt after 100 or so maps, using all 8GB of RAM.

Eek. That's no good.

So after 6+ years at this, we're all starting to hit production usage
where we stress the memory management system. Java's behaviour hasn't
always been pretty. 

The problem, I think is:

a) that GLib allocated memory is outside the visibility of the JVM

 cross product

b) the JVM garbage collector only runs when *it* thinks that it is out
of memory.

This second point is somewhat counter to expectation, but of late I've
noticed that Java doesn't "waste" time with full GC (let alone actual
page release back to host OS) until it thinks it is a last resort.

(in other words, there's sorta an enterprise-y assumption that it's the
only big thing running, so it doesn't need to be in a rush to return
resources. If OOM killer comes along and asks for pages then the JVM has
lots to offer, but until then you just get enormous VSZ sizes. I'm not
über thrilled about this.)

Anyway, the side effect of (a) × (b) is that our GObjects don't get
free'd until Java processes the Proxy object being out of scope and they
are finalized; that doesn't happen until the GC has done its thing. The
objects *will* get freed, but when is open to question.

So as an immediate debug, I would ask what the effect of sticking a
System.gc() in right after your Pixbuf goes out of scope. I know we've
all been trained out of making that call over the years, but it might be
worth offering the hint.

If that doesn't work, we'll look deeper. If it does work, we'll look
deeper.

AfC
Sydney