Is there a way to stop this, and is it a memory leak? Also, what are some alternatives I can use to help solve this?
Here is the code:
This is the size of the "map" and the first part are the x coordinates, and the latter is the y coordinates:
ATM I am using this code to "clean" the tiles:
An average output is this, and it's being called ever minute:
TileClean: Memory before: 51985kb Memory after: 35570 (Freed: 16415kb) Time: 311ms Tiles Cleaned: 0
Here is a picture of a JProbe snapshot:
I hope this is enough information, and I hope you guys can help.
David Newton wrote:It using too *much* memory? In other words, are you actually having an issue?
After like 10 hours of uptime it does, without constant garbage collection.
It increases at a rate of about 15MB per minute.
I'd like to reduce the amount of garbage collections needed, and possibly find a better way to store the ActiveTiles.
I'm pretty sure object pooling was discredited years ago as a useful Java technique, but if you're using an unusual JVM I'm sure it's possible.
Without looking through the code, I obviously can't tell you where that's happening. If you watched the JProbe memory graph as the application ran, you'd see which bars were growing the fastest, and shrank the most when the garbage collector ran. Those 3200 large bytes look suspicious, but I can't tell from this snapshot. I suspect your data structures could be more efficient if you'd like to bring down the total memory requirement, as well. Hell, you could save megabytes just by giving an argument of "2" to all those ArrayList constructors to make the initial size of the internal array smaller, and you could save even more by combining them all into one. There's no way every tile in the game has a large collection of each of those different object types.
The truth is, though, that in general you shouldn't call System.gc() yourself. Java knows how to manage memory very well, thank you very much, and by calling gc() explicitly, you almost always make things worse, not better. If your application isn't actually running out of memory -- and it's not, apparently -- then there's really not a problem here.
I'm really new at using JProbe (I got it today), is there a way to find out where those byte arrays are being allocated at?
I think that combining the lists into one would be more work than it's worth. And thanks for the tip on setting the initial size to 2 for those array lists, as I have tons all over the application.
I also removed the System.gc() calls, and the JVM is actually calling it at about the same times, I didn't think it would call it that often.
John Carr wrote:I have been using JProbe, and in the application, the ActiveTile class is using tons of memory, and total memory usage increases, then when a GC is called it cleans it all.
Is there a way to stop this, and is it a memory leak?
This is normal heap behaviour - memory size of objects allocated on heap increases, then if there is no more free memory to allocate a new object, JVM runs GC and cleans not reachable objects from heap.
This is not a symptom of the leak.
I don't know JProbe, but there must be a screen that shows memory usage on the heap over time.
Look at this example pictures from JConsole:
On the first picture, there is probably no memory leak - the amount of used memory after GC reaches the same minimum level after long running tme.
On this picture there is an obvious signal that there is probably a leak in the code - the amount of used (not freed) memory after GC increases over time.
To examine if there is a memory leak, run JProbe for 5 or 10 hours then examine screens of memory usage and you'll see it.