G
Guest
Hello,
I have posted earlier, asking about using a mobile device emulator in making
a game. I am almost completely done with the game, and it works
wonderfully... except on the emulator, where it will occasionally crash
because of a "managed out of memory exception."
I did a bit of investigation on this. Here's some facts:
1) When the program starts it uses 11 MB of memory.
2) As the game is played, this memory usage can go up to 15MB, but I have
never seen it go above that, and it sometimes drops back down.
3) Those facts were gathered when running the program outside the emulator
(i.e., just starting the executable in Windows). In the emulator, I can check
the system memory usage. At no point in the program's operation was there
less than 10MB of either storage or program memory free. There was often much
more.
4) The emulator's memory usage does not seem to be different when the game
is not running. That is, when I looked at the memory being used while the
game was running, shut down the game, and then looked again, the reported
memory usage was the same. I started up the game in the emulator again, and
the memory usage remained the same. So the emulator's ability to report
memory usage seems faulty.
5) There should not, as far as I can tell, be any reason for the game
program to progressively eat up 5MB of memory. It rarely creates new objects,
typically it just passes and creates references to objects that exist at the
start of the game and are never destroyed. The only time it makes new objects
are in functions, for temporary storage, and those are instance variables.
For example, the game controller has a declared, but not instancaited,
object of class Unit called unitData that stores the information about a
Unit. (Units, by the way, are what the game is played with; they represent
soldiers, cavalry, etc.) The GameSpace class (which represents the
inhabitable areas of the game environment) can create a new Unit based off a
Unit it has a reference to (i.e., this new Unit literally copies the data of
the other Unit) in a function and then said function returns a reference to
that Unit. Typically, unitData takes this reference. The "new" Unit that is a
copy of the GameSpace's Unit created in the function will have two references
to it: in the function, which should be deleted when the function is done,
and unitData, which only exists as long as it's needed and is then set to
null. This should, as I understand it, delete the object as it has no more
references to it and C# has automated garbage collection.
New objects like this don't get made very often. The only oft-created new
object is a bitmap of the game's background that is re-created from a bitmap
stored as an embedded resource when the game screen needs to be redrawn. In
this case, the background bitmap is redeclared as a new bitmap based of the
embedded bitmap, and the game stuff is drawn on it. Again, if the C# garbage
collection works the way I understand it, the declaration of a new bitmap
should delete the old one.
In other words, the apperent memory leak doesn't seem like it should even be
happening. Furthermore, the emulator never reports there being less than 20MB
free at any time. Although the emulator's memory report doesn't always seem
to be accurate...
And now I get a headache. I marked this as a question, but I think the only
one I can ask is, "What do you think is going on here?"
-GunnerJ
I have posted earlier, asking about using a mobile device emulator in making
a game. I am almost completely done with the game, and it works
wonderfully... except on the emulator, where it will occasionally crash
because of a "managed out of memory exception."
I did a bit of investigation on this. Here's some facts:
1) When the program starts it uses 11 MB of memory.
2) As the game is played, this memory usage can go up to 15MB, but I have
never seen it go above that, and it sometimes drops back down.
3) Those facts were gathered when running the program outside the emulator
(i.e., just starting the executable in Windows). In the emulator, I can check
the system memory usage. At no point in the program's operation was there
less than 10MB of either storage or program memory free. There was often much
more.
4) The emulator's memory usage does not seem to be different when the game
is not running. That is, when I looked at the memory being used while the
game was running, shut down the game, and then looked again, the reported
memory usage was the same. I started up the game in the emulator again, and
the memory usage remained the same. So the emulator's ability to report
memory usage seems faulty.
5) There should not, as far as I can tell, be any reason for the game
program to progressively eat up 5MB of memory. It rarely creates new objects,
typically it just passes and creates references to objects that exist at the
start of the game and are never destroyed. The only time it makes new objects
are in functions, for temporary storage, and those are instance variables.
For example, the game controller has a declared, but not instancaited,
object of class Unit called unitData that stores the information about a
Unit. (Units, by the way, are what the game is played with; they represent
soldiers, cavalry, etc.) The GameSpace class (which represents the
inhabitable areas of the game environment) can create a new Unit based off a
Unit it has a reference to (i.e., this new Unit literally copies the data of
the other Unit) in a function and then said function returns a reference to
that Unit. Typically, unitData takes this reference. The "new" Unit that is a
copy of the GameSpace's Unit created in the function will have two references
to it: in the function, which should be deleted when the function is done,
and unitData, which only exists as long as it's needed and is then set to
null. This should, as I understand it, delete the object as it has no more
references to it and C# has automated garbage collection.
New objects like this don't get made very often. The only oft-created new
object is a bitmap of the game's background that is re-created from a bitmap
stored as an embedded resource when the game screen needs to be redrawn. In
this case, the background bitmap is redeclared as a new bitmap based of the
embedded bitmap, and the game stuff is drawn on it. Again, if the C# garbage
collection works the way I understand it, the declaration of a new bitmap
should delete the old one.
In other words, the apperent memory leak doesn't seem like it should even be
happening. Furthermore, the emulator never reports there being less than 20MB
free at any time. Although the emulator's memory report doesn't always seem
to be accurate...
And now I get a headache. I marked this as a question, but I think the only
one I can ask is, "What do you think is going on here?"
-GunnerJ