gc machamisms in J2ME and J2SE are different. in J2SE, there is a daemon thread to collect garbage, when System.gc() invoked, JVM forces the thread to run.
But in J2ME, System.gc() collect useless memory immediately and return.
To quote the docs once again Runtime.gc()(1): The Java Virtual Machine performs this recycling process automatically as needed, in a separate thread, even if the gc method is not invoked explicitly.
You don't need to call System.gc(), as it will run when ever there is a pause in your application (waiting for input, IO bound operation, etc).
1) This is the siemens docs, but that is only due the fact Sun does not host the API docs in any other format then html.zip and pdf, it is identical to that shipped with the WTK. (The NDS does not seam to ship with the API docs)
There are memory allocation and collection bugs in Nokia JVM,you can see some other posts in the forum.
System.gc() does work, but when you create new object, JVM doesn't alloc the recycled memory,but request new memory from system.
System.gc() just calls Runtime.getRuntime().gc(), certainly in J2SE, and I see no reason why J2ME would be different. The JVM spec does not describe how or when the garbage collector works, just that it does(!)
In terms of when - the garbage collector must ensure that you do not get out-of-memory exceptions when there is memory available. So it *must* run when there is insufficient memory to create a new object, until either there is enough memory, or until all garbage has been collected. Only when there is no garbage can an out-of-memory exception be thrown. You never *need* to run the gc, as it will be run for you. But it takes time; the gc() methods are there to allow you prompt the process into action when it suits you.
The Nokia JVM does successfully recycle memory - run the Sun emulator and look at how much memory got allocated in total during the life of your program... if the gc didn't work your program would choke very quicky! On a series 40 (certainly 7210 and 6100, I think 6800 too) you are limited to 200k of heap and that's it. Symbian platforms are different - they can acquire extra heap space, and it is suggested that they may have some trouble giving it back... but any Java program that does much String manipulation (for example) would not survive for long even in 4Mb without successful garbage collection.
Are you sure that garbage collection isn't running when you do System.gc()? I notice on the 7210 emulator that memory only goes down, and suddenly shoots up when it hits zero - but without any apparent garbage-collection delay. Maybe the freeMemory() isn't always accurate?
ya, my Nokia 6800 hand phone didnt run "System.gc()" or "Runtime.getRuntime().gc()". i test it by "Runtime.getRuntime().freeMemory()" show on hand phone screen.
on the emulator, the "free memory" will be maintain at a point, however at real 6800 hand phone, the "free memory" is dropping when it start running. "free memory" start at "110000", then it will "reboot" when "free memory" is about reach "70000".
i really dunno y need "System.gc()" code??? y java didnt design as run garbage collector automatic when the object is no use.
one more thing is that i dunno whether real hand phone will run garbage collector itself or wait for the "System.gc()" command to call garbage collector???