Friday, March 24, 2006
Size doesn't matter
This week we've been in two conferences: Sun's Tech Days on Tuesday and the presentation of new configuration management product yesterday.
Meanwhile speakers show us all their products, I was realizing how difficult and different is game programming. Relational databases, O/R mapping frameworks, service based architectures, AJAX, OpenGL... and here we're fighting against bit shifting and juggling with three dimensions arrays which explodes our heap.
As Joel sais, all programmers write code, but each programmer in his/her own different world.
I'm going to tell you a real story, which Jaime has mentioned yesterday: our games are quite
big, specially taking into account memory capabilities of few handsets we support. The Fourth Seal has 12 levels and 9 different enemies, so it put our game at the level of some PC games, but running inside a small phone with 500 KB heap. This force us to squeeze phone memory and, as Jaime said, there're many things in heap when it mustn't be here.
If you write desktop or server applications, probably you don't realize if you're wasting your memory. It will be just enough detecting and fixing memory leaks, and ensuring memory requirements don't raise too much.
But in our world it's really important.
One thing we has in memory and hindered us, was executable instructions (bytecodes) of some methods. We have a lot of preprocessing code, which is responsible of create offscreen images, read data from disk, sort lists, decompress data, etc. and all that code only is executed once, duing game startup, so we wanted to took that load off our shoulders when it wasn't needed any more.
But... how? Java (and of course J2ME) do not offer any way to unload memory of one specified method... well, there aren't any direct way, but it isn't all lost.
Our solution goes tru joining all that "use and throw out" code in one single class. When first class instance is created, all bytecode will be loaded in memory and when last instance is released and garbage collector called, all those bytecodes will be freed from heap. Simple and easy.
Getting memory graphs (like you can see up there), you can see two sudden memory drops. It is just the moment when last "loader class" instance is freed and garbage collector invoked.
As it's used to say: size doesn't matter, except if you're programming phone games!!
Meanwhile speakers show us all their products, I was realizing how difficult and different is game programming. Relational databases, O/R mapping frameworks, service based architectures, AJAX, OpenGL... and here we're fighting against bit shifting and juggling with three dimensions arrays which explodes our heap.
As Joel sais, all programmers write code, but each programmer in his/her own different world.
I'm going to tell you a real story, which Jaime has mentioned yesterday: our games are quite
big, specially taking into account memory capabilities of few handsets we support. The Fourth Seal has 12 levels and 9 different enemies, so it put our game at the level of some PC games, but running inside a small phone with 500 KB heap. This force us to squeeze phone memory and, as Jaime said, there're many things in heap when it mustn't be here.If you write desktop or server applications, probably you don't realize if you're wasting your memory. It will be just enough detecting and fixing memory leaks, and ensuring memory requirements don't raise too much.
But in our world it's really important.
One thing we has in memory and hindered us, was executable instructions (bytecodes) of some methods. We have a lot of preprocessing code, which is responsible of create offscreen images, read data from disk, sort lists, decompress data, etc. and all that code only is executed once, duing game startup, so we wanted to took that load off our shoulders when it wasn't needed any more.
But... how? Java (and of course J2ME) do not offer any way to unload memory of one specified method... well, there aren't any direct way, but it isn't all lost.
Our solution goes tru joining all that "use and throw out" code in one single class. When first class instance is created, all bytecode will be loaded in memory and when last instance is released and garbage collector called, all those bytecodes will be freed from heap. Simple and easy.
Getting memory graphs (like you can see up there), you can see two sudden memory drops. It is just the moment when last "loader class" instance is freed and garbage collector invoked.
As it's used to say: size doesn't matter, except if you're programming phone games!!
posted by JM : 8:20 pm
