1

I'm making a fast-paced realtime Android game, and everything works great, but the first couple of seconds when the game starts are very laggy because the garbage collector is cleaning up after the loading thread. Sure, the player could wait a few seconds (like 10+ sec) because after its done it starts running perfectly smooth, but that looks really ugly and feels like the game is buggy.

Is there a way (or technique) to tell when its safe to start the game so the garbage collector won't start going crazy as soon as the real-time part begins? the big fat loading thread can't be reduced much without breaking things.

Improve this question
6
  • 1
    "very laggy because the garbage collector is cleaning up after the loading thread." - doesn't that suggest you are churning memory during load, or is it just load time? If the former, is that something you could avoid? Commented Jan 6, 2012 at 0:28
  • @Mitch: It suggests that the loader uses a lot of objects (or some number of large objects). Could be none of them are eligible for collection til initialization is complete. Commented Jan 6, 2012 at 0:33
  • @cHao: I'm curious as to why the loader would need lots of objects? Commented Jan 6, 2012 at 0:37
  • @Mitch: Because it's setting everything up and getting the app ready to run? There's probably all kinds of config loading, resource finding, XML parsing, etc etc etc going on...once everything's configured and loaded and ready, much of that stuff can be tossed out. But til then, there's gigantic trees of stuff the loader still has a reference to. Commented Jan 6, 2012 at 1:04
  • @CHao: I reckon it's more likely the JIT rather than the loading per se. (as Stephen C mentioned) Commented Jan 6, 2012 at 1:05

3 Answers 3

Reset to default
3

This seems like a case where System.gc() might help. It tells the system that this would be a good time to collect garbage. According to the documentation,

When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

The docs also say, though, that the method "suggests" that objects be collected -- that is, there's no guarantee it'll help, particularly if you still have some references squirreled away. If it does work, it'll only collect objects that are not reachable at all from the running code, including the runtime. (That loader thread, for example, is not eligible for collection til it's finished running and your code has no more references to it.)

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

You can run System.gc() right before you start the game to manually force the garbage collector to run (and, according at least to the official JavaDoc here, finish before returning from this method call). However, the GC in general is nondeterministic and there is no guarantee that it will not be run again or, for that matter, that the call to System.gc() will do anything at all.

Improve this answer

1 Comment

True, but this question seems to indicate that the System.gc() does do something on android, and I think this is a very legit case to run the GC. It certainly won't hurt.
1

If you looked into this more deeply you will probably find that much (even most) of the "lagginess" is not the GC's fault. I suspect that it is mostly due to JIT compilation. Calling System.gc() could improve things, but I doubt that it will get rid of the lagginess entirely.

Improve this answer

1 Comment

I don't think thats the problem because when the lagg occurs, my logs show a bunch of lines that say "GC_CONCURRENT ...blah blah blah..." and those stop showing up after the lagg goes away :\ EDIT: plus, I only started noticing the lagg after my game started become more and more complex and I had to add more and more to the loading function. It didn't lagg this much in the beginning

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.