profiler not showing decreasing Runtime.getRuntime().freeMemory() allocations

[lemmy101]

Here's an odd one I'm hoping people can help me with.

I'm writing a game, and am printing Runtime.getRuntime().freeMemory() onto the screen every frame.

What I'm finding is that the memory is starting at about 125 meg, and quite rapidly decreasing to about 50 meg, then jumping up to 125 meg (or there abouts) again, and then doing it again, and so on.

This suggested to me that a huge amount of memory is being allocated and discarded, and then freed by the garbage collector.

So I've profiled it in netbeans, and have taken a snapshop when it's at 125 meg and various others between, as I approach 50 meg.

But when comparing the profile reports, I see absolutely no new allocations accounting for that amount of memory. A meg or two at the most in small point / position classes, iterators and such, but that's it.

I'd like to be able to rely on having > 100 meg but I worry if I drop below 75 as the peak I'll run out of memory at the end of these cycles. Or will the GC run earlier / more frequently to compensate?

Anyone got any ideas what I could look for to find where this memory is going? :S

Thanks in advance,

lemmy

[quad64bit]

Well, java does tend to fill all available space before running garbage collection, thats pretty common. As far as leaks, you might make sure that you are disposing of any Graphics or Graphics2D objects you are using. If you set the memory limits on java much lower, does it run out of heap space or does it exhibit similar behavior?

[lemmy101]

I tried allocating a huge amount of memory so I only had 8 meg free at launch, and it avoided the out of memory error with garbage collects so I'm a happy coder :)

Still non the wiser where the memory is going, but as long as it comes back on demand with just a tiny pause, then I'm content for now. ;)

thanks! :)

[quad64bit]

I'm sure you have a leak, or are trying to load way too much into memory at runtime, but without a code sample, its hard to say. Bitmaps (buffereImages) and the like use a LOT of memory in java since they are uncompressed. Its wise to load them as needed and to reuse sprites where possible.

[lemmy101]

There's way too much to provide a code sample.

I figured out where the memory decrease is coming from. It seems to be happening in the pathfinding, if I comment that behaviour out the memory stays 100% static. It's weird though the profiler doesn't account for such a huge amount of memory :S any other free ones I could try?

[quad64bit]

Are you putting things into an arraylist that doesn't get cleared?

[quad64bit]

Or a recursive operation perhaps that continues to grow as you go? (Filling the system stack)?

[lemmy101]

The only thing I can think of is iterator generation, I'm doing this (or rather code I've implemented into my project is doing this):

SortedList.add(Thing thing)
{
list.add(thing);
Collections.sort(list);
}

basically it's a sorted list class which is sorting the elements after each add. So iterators from the sort will be generated each time something is added to the list, and there is likely to be a lot of these per frame.

Is there a garbage free way to sort members of a collection in java? without writing your own sort function of course...

Either way, the thing that confuses me is the lack of reported allocations in the profiler. If it was items in an arraylist not getting cleared, or a recursive function allocating new memory, or a big bunch of iterators being garbage collected, then you would expect surely to see 75 megabyte of newly created objects in a comparative report of when the memory profiler snapshoted at 125 meg, and snapshoted when it was 50 meg (where it shows +/- memory / instances per type). I don't understand why the biggest memory change reported for a type is about 1.5 meg of data, and there is only about 4-5 meg extra accounted for in the entire profile results, no +75,000,000 bytes of Iter type listed or anything which seems like a massive number to go unaccounted for. Seems to me this means either memory profiling, or GetRunTime().FreeMemory tracking, is next to useless, as one of them is clearly either incorrect or omitting vital information.

[quad64bit]

I'm not entirely sure... Are you sorting after every insert? Perhaps you should look at a different data structure?

[Tolls]

Your snapshot is probably ignoring anything that is eligible for collection.
The main purpose of these things is to identify leaks, so anything eligible for collection is not a candidate for a leak.

Since your memory usage appears not to be going up then I would argue you haven't got a memory leak.