CODEWITHSUNDEEP
javawindowseclipsememory-leakslibgdx
pixlhero
pixlhero

Reputation: 41

Empty LibGdx game loop leaks Memory

I was debugging my game which I wrote using the libGdx library with eclipse. I had a massive memory leak so I commented out lines in my render loop until I was there with nothing. But the Ram of the application was still rising. I ended up creating a totally new project with the GTX setup UI. And when I started it the axact same thing occured. It is still raising at the speed of ca. 4 Kilobyte per second. Not much, but it just won't stop. when looking at the heap datas I saw that there was com.badlogic.gdx.backends.lwjgl.LwjglInput which was probably causing it. But I don't know if I even am supposed to change something, when this "problem" is even in the project created by the GTX setup UI. Is this normal for an application? I waited until it raised from 34'800K to 40'000K so it probably won't ever stop. Will this cause a OutOfMemory Exception eventually? (btw. I used the Windows Task-Manager for the RAM values. And I'm using Eclipse)

Upvotes: 1

Views: 1563

Answers (3)

Robert P
Robert P

Reputation: 9823

If System.gc() solved your Problem it was only, like the others said a lazy GC. But normaly the GC will run automatically when needed. So you should not call System.gc() as 1) it only tells the GC he should run but it is not sure that he does and b) GC takes a lot of time so if you want to do this every second, even if it is not necessary it may cause FPS to drop. If you are interested in System.gc() there are a lot of discussions about it. Most programmers say it is bad practice and the GC knows when he should run.

Upvotes: 0

bemeyer
bemeyer

Reputation: 6231

log the GC by adding -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps as a VM argument and youll see when the GC gets called automatically. To see how much RAM your application really need you use the tool from Oracle (jconsole.exe). Everything else isnt correct what you see. You just see the VM and it is not aquivalent to the programm itself. (at desktop my app does have like 80mb of ram but the game itself just need around 11mb!) You can also see if you produce alot of objects the whole time without "deleting" them. If so you need to check your mainloop if you create objects in it what you clearly shouldnt do. Just check the progrmam out it will tell you alot of stuff about your application. But it does just work with the desktopverison. But since the desktop is "simelar" to the android version you should do fine with it.

The System.gc() is a good turn but does eat alot of time if you call it at your mainloop because it's a kind of "deepclean". So try to avoid this. Call it on mapchanges or stuff like that where you dont notice a lag.

Upvotes: 1

noone
noone

Reputation: 19796

It is not necessarily a memory leak. When the garbage collector will be triggered can be pretty random and sometimes not happen for a long time. Especially if there are only 4kb/s being allocated. The triggering of the GC is also dependent on the JVM you are running in. Dalvik on Android might trigger it more early.

As you tried yourself, calling System.gc() to trigger the GC yourself prove that it was not a memory leak, but just a lazy garbage collector.

On desktop (LWJGL backend means desktop only) this is not very critical, since you won't feel the garbage collector. On the mobile backends I'd expect the libgdx developers to be more careful with new instances, which means they will probably use Pools a lot more than in the other backends, to avoid the garbage collector as much as possible.

Upvotes: 3

Related Questions