memory jump while running game

[TacB0sS]

I wrote a pacMan for cellular and there was something very troubling while running, a small jump every now and then, took me a while to understand where it came from but I found it, the memory usage of my game goes as follow:
Memory usage: 1739796/2097152
Memory usage: 1738500/2097152
Memory usage: 1734696/2097152
Memory usage: 1730936/2097152
Memory usage: 1729640/2097152
Memory usage: 1725792/2097152
Memory usage: 1722076/2097152
Memory usage: 1720736/2097152
Memory usage: 1716316/2097152
Memory usage: 1713172/2097152
Memory usage: 1711876/2097152
Memory usage: 1707456/2097152
Memory usage: 1704312/2097152
Memory usage: 1703016/2097152
Memory usage: 1698552/2097152
Memory usage: 1695452/2097152
Memory usage: 1694112/2097152
Memory usage: 1689692/2097152
Memory usage: 1686548/2097152
Memory usage: 1685252/2097152
Memory usage: 1680832/2097152
Memory usage: 1677688/2097152
Memory usage: 1676392/2097152
Memory usage: 1671972/2097152
Memory usage: 1668828/2097152
Memory usage: 1667180/2097152
Memory usage: 1663068/2097152
Memory usage: 1659968/2097152
Memory usage: 1657704/2097152
Memory usage: 1654208/2097152
Memory usage: 1651064/2097152
Memory usage: 1648844/2097152
Memory usage: 1645304/2097152
Memory usage: 1642204/2097152
Memory usage: 1639940/2097152
Memory usage: 1636444/2097152
Memory usage: 1633300/2097152
Memory usage: 1631080/2097152
Memory usage: 1625736/2097152
Memory usage: 1624176/2097152
Memory usage: 1622176/2097152
Memory usage: 1616920/2097152
Memory usage: 1615272/2097152
Memory usage: 1613052/2097152
Memory usage: 1270624/2097152
Memory usage: 1243680/2097152
Memory usage: 1152348/2097152
Memory usage: 784996/2097152
Memory usage: 744000/2097152
Memory usage: 649532/2097152
Memory usage: 269588/2097152
Memory usage: 227268/2097152
Memory usage: 129608/2097152
Memory usage: 1831812/2097152
Memory usage: 1828068/2097152
Memory usage: 1826772/2097152
Memory usage: 1822880/2097152
Memory usage: 1819208/2097152
Memory usage: 1817868/2097152
Memory usage: 1813272/2097152

painter Data over a loop count of 323:
Averege sleep=5.6006191950464395
Averege execution time:34.39938080495356


note the bold line at this point some thing happens, and the game pauses for "10 ms" (very short period) and goes on, i know it is not much but it is noticeable and can drive me nuts, what may cause this memory behavior?

thanks,

Adam.

[raj_J2ME]

Hi,
How you have implement the run() method?
How you are painting the canvas?
Where in the code/How you are loading the images and rest of the resources?
Have you open the memory monitor,and can you please check that what sort of things,like String,images,chars,etc,exactly is leading to that much memory jumps,

[grahamhughes]

What are you running this on?

The memory is dropping down quite smoothly, with some occasional big drops, like from 1,613,052 to 1,270,624 (at which point, I assume you load something).

I'd guess the pause occurs after the two lines you have in bold, when the free memory jump up from 129,608 to 1,831,812. At this point, the garbage collector has executed.

You could insert a System.gc() call in the game's run() loop. This can spread out the garbage collection effort, so that the game runs more smoothly. However, System.gc() executes very slowly on Series 60s. You can use conditional compilation to build for different devices, like this:

if (Device.USE_FREQUENT_GC) {
    System.gc();
}

Where:

public class GenericDevice {
    // do this as "standard"
    public static final boolean USE_FREQUENT_GC = true;
}

public class Device extends GenericDevice {
    // disable this code for Series 60
    public static final boolean USE_FREQUENT_GC = false;
}

You can have a different version of the Device class for each target device (or device-group).

You might find that the same problem does not appear on an actual device.

Also: follow Raj's advice, and use the memory monitor to find out more. If you don't find an answer, let us know the answer to Raj's questions so we can help you more.

Cheers,
Graham.

[TacB0sS]

i run it on wtk 2.5.2 and dsdp 9.1 on eclipse

thing is, this memory jump occur every now and then, and for my best knowledge I don't load anything the game runs in a loop all the loading is done at start up I have a thread for painting which repaints the canvas, all the objects on the screen are components i design with paint(Graphics g) method on a container which holds them all, I'll have to go through my code to be sure there is no unnecessary loading of big objects but i'm pretty sure this does not happen!

any other reason this might happen on run Time except GC??

[TacB0sS]

WoooooooooooooWWWWWWW it worked, the System.gc() fixed it.

Thank you...

[grahamhughes]

Java programs create garbage constantly, you can't really stop it. Any jump up in the amount of free memory is because the garbage collector has executed. (Or, on devices with expandable heaps, because the heap has expanded... but this only happens immediately after the GC runs anyway.)

Graham.

[raj_J2ME]

WoooooooooooooWWWWWWW it worked, the System.gc() fixed it.

Thank you...

Hi,
Make sure that the call to the System.gc() must not be made inside the infinite loop,Better you call this on the keypressed,or after a fixed time interval.

[TacB0sS]

yes, Ive noticed that when it is inside the update loop the average sleep time of my application went from 4 ms to -5 ms

[grahamhughes]

This will depend on what virtual machine you're running on. If the VM uses a single heap, then running gc() often should not be a problem. If the VM uses a generational heap (like Series 60), then gc() is very, very slow. Before you tune performance, see how it works on an actual phone. You might find that on a real phone, the stutter disappears completely, and you don't need the gc().

On the subject of sleep()ing... I recommend that the loop always sleep() for some minimum time (or at least, build in some provision for this to happen).

long sleepTime = FRAME_DURATION - (endTime - startTime);
if (sleepTime < MINIMUM_SLEEP) {
    sleepTime = MINIMUM_SLEEP;
}
if (sleepTime > 0) {
    try {
        Thread.sleep(sleepTime);
    } catch (InterruptedException e) {
        // ignore
    }
}

You may need to adjust MINIMUM_SLEEP to performance-tune different devices. It might be as low as zero, or as high as 15ms.

If the update loop thread never sleeps, it may consume all the cpu resources and prevent other threads from running. "Other threads" includes the event-delivery thread, which means that keyPressed() events might not be delivered promptly, making the game feel unresponsive. (This sounds like it shouldn't happen, but mobile devices don't necessarily have sophisticated thread scheduling.) Adding a minimmum sleep in these cases will slow the game down, but can actually make it feel faster by making it respond to input better. Again, this is device dependent, and creating a "Device" class (as shown earlier, contains constants with device-specific information) can help you code for multiple devices without making code changes.

Graham.

[TacB0sS]

I see what you mean, it makes sense. The thing is, i check my code and i do not create new object at all in the update paint cycle, so why does the memory runs down so fast with out the gc()?

perhaps I don't really understand the memory usage of java, is there a good reading material to read about memory using in java?

[grahamhughes]

There are always new objects being created. The Graphics object passed to paint(), for example. Any kind of String manipulation. Any temporary objects created by API methods that you call. The local variable frame created every time a method is called.

Arrays are objects. This line:

int[][] a = new int[3][3];

creates four new objects: one int[][] and three int[]. Objects typically consume 16 bytes, plus the space they need rounded up to a multiple of four. That 3x3 array of ints, that you might think needs ((3 * 3) * 4) = 36 bytes (4 bytes for each int) actually consumes 16 bytes of overhead + 12 bytes of data (4 bytes per int or per object reference) for each of four arrays (112 bytes).

On the subject of arrays, beware of code like:

int[] a = new int[] { 1, 2, 3 };

This compiles exactly like:

int[] a = new int[3];
a[0] = 1;
a[1] = 2;
a[2] = 3;

So it can generate much more code than you expect (if you're from a C or C++ background). It can also mean you're executing a lot of code (and generating garbage) for what you thought was a simple pointer copy. Might not be a problem if this code is in a class-initializer, but in a method, or especially in a loop...

A String is an object (16 bytes) containing an int (4 bytes) and a reference (4 bytes) to a char[] (which is an object (16 bytes) containing two bytes per character). Total, 40 bytes + 2 bytes per character (rounded up to a multiple of four). A large number of small strings can take a lot more space than you think.

if (someString.trim().toLowerCase().equals("fish")) {

This line creates two String objects (one the result returned from trim() and the other returned from toLowerCase()). If the string was four characters long, then that's 96 bytes gone. (Plus any space used by those methods.)

So, back to your free-memory log... there are lots of fairly small drops, say 1000 bytes, and that is what I would expect to see. However, you have some much larger drops (as much as 400k), so something else must be going on there.

Be wary of worrying too much about memory allocation in the emulator. Worry only if you're seeing the same behaviour on the device. It is easy to spend a lot of time chasing down bugs or other issues that turn out only to happen on the emulator!! In this case, by "behaviour", I don't mean "memory drops and drops, then bounces back up". You *will* see that. I mean, if it stutters on the device. You probably won't... the emulator's VM has been tuned for debugging, whereas the VM on the device will have been tuned much more for performance.

As Raj mentioned in an earlier post, there is a memory monitor in the wireless toolkit that will tell you things like how many objects of what types you have. If you want to investigate further, try using that tool to see what's going on.

Hope that helps some.

Graham.

[raj_J2ME]

Great explanation so far,
Thanks Grahm,

[TacB0sS]

wow thanks for the info, really great example, the thing is i thought that objects that are declared within brackets such as

public void blah() {
    if(true) {
        int integer=5;
        integer++;
    }    // this is the line i talk about
}

i thought the integer object memory is been cleared at the closing bracket noted in the code, i did not think i have to call gc() on it...


and can i access the memory monitor via eclipse?

thank you so much for all your responses,

Adam

[grahamhughes]

You never need to call System.gc(). The gc will run automatically and release space. As a rule, you should avoid calling it manually.

It would be possible to allocate the local variable space from a stack, but it can be allocated from the heap. If a stack is used, variables would be freed at the end of the method. The local frame has a fixed size for the duration of the method.

If that int had been an Object-type, then although the variable would not be freed, the object is refered to would become garbage at the point the variable goes out of scope (technically, at least - I wouldn't rely on it until the method ends).

No idea, I've never used the memory monitor. Can only suggest you play and see.

Graham.

[raj_J2ME]

HI '

can i access the memory monitor via eclipse?

Which SDK you are using with the Eclipse.If this is the WTK,then this can be open like this,
1.Open the start button and then WTK
2.Then Utilities
3.Then you will find the list if tools,
4.Click on the Memory Monitor
5.Click this,
Then try to run the project,

IF you have some other than WTK,like the Nokia SDK then you can run the project then you can go to the preferences and then the memory monitor.
Please check that whether these lines can be of any help,