How could I decrease the peak of vm memory?

Started by kiffa, October 11, 2013, 02:29:19 PM

Previous topic - Next topic

kiffa

As I know, android used a non-compacting GC before 3.0(https://groups.google.com/forum/#!topic/android-developers/7VeEnvcF1CE),  which will not return the vm memory to system for external memory(non-vm-memory) using, but the external memory can be returned to system for vm memory using. For example:


// Assuming the memory limit of process is 24M, and the usage of memory of a app now is 1M/2M(vm),  1M/2M(external)
byte [] tmp = new byte[1024*1024*20];  // 21M/22M, 1M/2M
tmp = null;
system.gc();//1M/22M, 1M/2M, there are 22M vm-memory allocated, 1M used, 21M free;
//trying to allocate 3M-external memory will cause an OOM, because the heap don't shrink for external memory.
new Bitmap(xx); //before android 3.0, bitmap alloacate in external memory.
//or
ByteBuffer.allocateDirect(3*1024*1024);


So if I want to avoid OOM, I must control the  peak of vm memory.

I found when loading/uploading asserts(models and textures), the engine will cause a high peak of memory usage, when all things done(after uploading/virtualizing), the peak will drop down much(but the vm memory won't return as saying before). So when I finished 3D-scene, return to 2D view activity(with many bitmaps\external memory), the OOM happens frequently. There is enough memory, but the peak is unreasonable.

Could I decrease the peak of vm memory when loading/uploading assets? For example:

Decreasing the tmp buffer for uploading(for 16-depth bitmap, using short[] instead of int[]);

Converting-uploading-freeing memory of asserts one at a time, instead of converting all -> uploading all -> freeing all

EgonOlsen

You can try to add some calls to http://www.jpct.net/jpct-ae/doc/com/threed/jpct/World.html#compileAllObjects() here and there, so that object compilation and native memory reservation happens at setup and not at runtime. However, i think that the texture uploads will cause larger peaks. There's not very much that you do about that. You could decrease texture size or use 4bpp mode for the textures, but i don't think that it's worth it to fight a virtual problem only. How large is your largest texture?

kiffa

#2
4 largest textures of 512X512, 1 texture of 256X128, plus 10-15 textures of 64X64, and a few(1-3) textures of 128X64.

My scene has about 90000+ vertices.

And my lowest target is the device of 24M-memory limit & Android 2.3.

I can reduce the size of asserts, but I think there are some optimizing methods beyond that such like what you saying above. I will try World.compileAllObjects, thanks.

EgonOlsen

If reducing the initial memory peak is still an issue, you might want to try this jar: http://jpct.de/download/beta/jpct_ae.jar and set Config.reuseTextureBuffers=true;

I'm not sure if it helps or hurts, but i would be interested in the results.

kiffa