4
\$\begingroup\$

I found that you can control your memory usage on libgdx with:

int javaHeap = Gdx.app.getJavaHeap();
int nativeHeap = Gdx.app.getNativeHeap();

But, How can I force a garbage collector cleanup? I want to force in special moments, like screen change on a game.

\$\endgroup\$
1
  • \$\begingroup\$ My issues is same as you, @Zhen, but not on getJavaHeap nor getNativeHeap(). When I'm performing several screen changes, I tested on the desktop and it worked countlessly but not in device, which ends up at 6th or 7th screen. \$\endgroup\$
    – David Dimalanta
    Commented Jan 29, 2013 at 3:38

3 Answers 3

Reset to default
6
\$\begingroup\$

Java's garbage collector is nondeterministic. There's System.gc(); but it will likely do nothing. See the StackOverflow question for further discussion.

\$\endgroup\$
8
  • \$\begingroup\$ I have a question, @Anko. Is it a bad practice to call or declare a forced garbage collector according to your answer? \$\endgroup\$
    – David Dimalanta
    Commented Jan 29, 2013 at 3:42
  • 2
    \$\begingroup\$ @David There's a SO question about that too. A summary of the answers: It is bad practice. System.gc(); is not defined to do any particular thing. Depending on many unknown factors, it may do one of many even potentially harmful things. \$\endgroup\$
    – Anko
    Commented Jan 29, 2013 at 10:24
  • \$\begingroup\$ Then that means I have to make the program nice and simple, right? \$\endgroup\$
    – David Dimalanta
    Commented Jan 30, 2013 at 2:24
  • \$\begingroup\$ @David You always should! :) \$\endgroup\$
    – Anko
    Commented Jan 30, 2013 at 9:30
  • \$\begingroup\$ There is another question regarding your answer, @Anko. Is it won't matter even if I manage the memory using a simple Java's getters and setters, virtual memory will still depleting or there is an exception when using a static keyword? \$\endgroup\$
    – David Dimalanta
    Commented May 9, 2013 at 8:04
2
\$\begingroup\$

Many of the libgdx classes have memory allocated across JNI. Destroying/disposing of classes should handle this for you. Forcing a GC call may not be de-allocating classes if they reside in native managed memory. Last time I used libgdx, it provided decent logs of when memory was allocated/destroyed. Do yo have a specific issue when loading new screens?

Update: Based on this page, there's a screen.dispose() and comments suggesting that you should reuse your screen class to avoid GC.

\$\endgroup\$
2
\$\begingroup\$

While you can give a hint to the runtime engine via System.gc() this is a "hint" and not a command so you cannot rely on it to actually trigger garbage collection. Even if it were a command, forcing garbage collection is unlikely to accomplish what you want- the garbage collection process itself consumes resources so when it runs your game will be impacted. So, in fact, you want to avoid garbage collection to ensure your game isn't contending with the GC process for resources, see this link for a libgdx specific discussion: http://code.google.com/p/libgdx-users/wiki/ForceGarbageCollection

Instead of dynamically allocating many short lived objects that require garbage collection I think the better strategy would be to allocate long life objects at times the user isn't playing, e.g. loading screen or first start up. These objects can even be returned to a pool when no longer needed and then reused as necessary.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .