1

I'm developing a android game and i have a question about storing the game elements without firing garbage collector.

My game needs a collection where the game elements are stored according to x,y positions (all game elements have x,y,width and height). The collection is then called every frame to retrive the elements according to cameraX,cameraY,camera width and height (user can scroll around the game).

Example: 

 function draw() {
   tmp = collection.getElements(tmp,cameraX,cameraY,cameraWidth,cameraHeight);
     for(int i = 0; i < tmp.size(); i++) {
        tmp.get(i).draw();
     } 
  }

I'm currently using the Vector class to represent the collection elements, but the gc keeps firing every couple of minutes. I do all my allocations up front. I've also modified the getElements function to accept 1 more parameter - a temp vector(allocated upfront) which is filled with elements and then returned.

  • With which class to store the game elements so the gc wont fire (i prefer never if possible)?
  • i also add elements to the collection during runtime, do i have to allocate them upfront also?

Thanks,

Regards J.

blejzz
  • 3,349
  • 4
  • 39
  • 60

2 Answers2

0
  1. If you have a reference on an object, GC will not collect them. So if you don't create objects (and release them) during your game your GC will never free the memory
  2. If you need to create your elements upfront depends on the type of elements. If they have to read data from the file system, you should load them before in a boot/loading sequence. If they are simple you can do it when you need them the first time
WarrenFaith
  • 57,492
  • 25
  • 134
  • 150
  • GC must run to determine if there's a reference, so the logic of #1 is flawed. (Of course it's perfectly possible that it never runs if there are no new allocations.) –  Jun 07 '11 at 15:10
  • @delnan True, but it will not result in the hick-up that appears when it actually releasing some memory, right? – WarrenFaith Jun 07 '11 at 15:13
  • The real bottleneck of a GC cycle is stopping the run to determine reachability, not actually freeing memory (with copying GCs, it's slightly more important, but still not the main cause of slowdown). –  Jun 07 '11 at 15:17
  • i've noticed that the code below fires the gc, any ideas how to bypass it? while (running) { try { c = holder.lockCanvas(null); synchronized (holder) { // render } } finally { // do this in a finally so that if an exception is thrown // during the above, we don't leave the Surface in an // inconsistent state if (c != null) { holder.unlockCanvasAndPost(c); } } } – blejzz Jun 07 '11 at 15:21
  • @Delnan do you have a resource for that? Because my experience so far is that the GC creates lags when freeing memory, especially large amounts and never create any lag when it just run without freeing anything. – WarrenFaith Jun 07 '11 at 15:21
  • Depending on the exact GC used and the mixing of live/garbage objects in the memory layout, that may be true (if every second object is live and the GC is compacting, it spends a lot of time copying). I wouldn't expect it in general though, as freeing memory isn't a huge task but walking the whole heap is. (Generational GC may also alleviate this somewhat, admittedly. Does Android have one?) See any material on GC algorithms. –  Jun 07 '11 at 15:26
  • @delnan: This http://stackoverflow.com/questions/4818869/technical-details-of-android-garbage-collector suggest its tracing algorithm, this http://stackoverflow.com/questions/4859424/garbage-collector-in-android-2-3 talks about a combination... I couldn't find a good resource for that... I just can rely on my own experience... – WarrenFaith Jun 07 '11 at 15:33
  • i've managed to achive that if the game runs (just rendering objects) the GC is called in about 10 minutes from start, but don't know why exactly it's called.. There is no actual change in the game run function.. Could it be the emulator or i screwed up something? Or is the vector class? – blejzz Jun 07 '11 at 15:46
0

Once every several minutes might not be a problem worth worrying about right now, are you getting a noticeable frame rate drop when it triggers? Another option is to just call System.gc() when it's convenient for you.

Michael Apfelbeck
  • 310
  • 1
  • 8
  • `System.gc()` is just a `it would be nice if you do it now` but its not an actual call to run the GC right away – WarrenFaith Jun 07 '11 at 15:48
  • i've managed to tweak the code so it gets called every 10minutes or more, but it is noticeable. But don't really know why it's called (the code is always the same, nothing new is triggered).. Is it because the Vector or the emulator? The logcats says GC_FOR_MALLOC freed X objects / X bytes in 180ms.. – blejzz Jun 07 '11 at 15:56
  • @jarnej, is that 180ms on hardware or on the emulator? The emulator is pretty slow and your real world perf should be better. Are you tracking the number of frames between garbage collections? I'm curious to know if it turns out to be 1 object/frame or something. – Michael Apfelbeck Jun 07 '11 at 16:20
  • on the emulator.. i used the ddms and saw the allocation which was my fault :P i've fixed it and now testing to se if it is gona fire again – blejzz Jun 07 '11 at 16:41