Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Memory Leak?

 
John Carr
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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? 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.

Regards,
John Carr
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It using too *much* memory? In other words, are you actually having an issue?
 
John Carr
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure how we can help at this point--it depends on quite a few factors.
 
John Carr
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:I'm not sure how we can help at this point--it depends on quite a few factors.


Such as?

Also, can you tell if there is a memory leak? Also, would object pooling help in this situation?
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Finding a memory leak requires all the code--we have no idea what might be holding on to your objects.

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.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, I don't think it's a leak. In Java, a "memory leak" is when objects you no longer need are still referenced, so the garbage collector can't discard them, so they pile up and eventually you run out of memory. What you have is simply too much garbage -- you're allocating too many objects and then throwing them away.

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 byte[]s 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.
 
John Carr
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the information.

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.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't used JProbe in years, but in general these tools have some way to get a list of all the objects og a given type (maybe just double-clicking a bar in this bar graph) and then in the ensuing list, you can get some additional info about each object by double-clicking again. Info about where each object is allocated may be part of that; if not, there may be a setting you can make to turn collection of that info on.
 
Ireneusz Kordal
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic