11-17-2008 10:22 AM - edited 11-18-2008 09:28 AM
Any advice on how to debug a midlet that gradually begins to slow down if left running for a long time (eg. a couple of hours...) Output from the app doesn't seem to indicate that the app itself is consuming resources.
Would it help if I had a better understanding of the JVM: output?
11-17-2008 11:35 AM
Presumably there is some way in the emulator to dump the list of objects but I have no idea
what it is. You'd have to suspect something like forgotten references, forgetting to clean out a
vector, etc. If you think it is memory + constant GC, you might be able to get some
info from the system memory methods. Do actually get a chronic hour glass of just notice
slower response? I assume you have ruled out network issues?
If you are doing things like exhaustive searches and failing to keep the list trimmed that
would be a suspect for speed. What does your program do, do you have no suspects?
11-17-2008 03:00 PM
Thanks for the advice. I do now think that it might be memory. Definitely not network. I just noticed that the app becomes progressively slower every time I return from sleep mode; possibly reallocating a lot of memory each time it wakes up. (It has to build a fairly complex screen from an XML file.)
I"ll monitor the memory and see what happens.
11-17-2008 03:04 PM
You might also try using the profiler tool in the JDE. This allows you to take a snapshot of the object handles and memory usage, then run the program for awhile (or through some suspect code section) and compare a later snapshot.
11-18-2008 08:23 AM
This is another reason I wished you could easily run your code with the Sun JDK and no emulator as
there are more options to play around. In any case, sure the jvm maintains a lot of information on
allocations. But, it uses this to prevent you from doing anything too confusing. So, the suspect list
for problems like this, short of a jvm bug, is pretty limited. Even without a profiler or heap dump,
it probably isn't too hard to check all your loop conditions and consider if they are getting progressively
wider- do all your collections have conditions to keep their sizes limited for example? Do you have
nested loops that give your code something like O(N^2) performance problems?
Locks can be another source of slowdown, do you have everything synchronized and create conditions of
lock starvation? Don't ignore the obvious either, sleep(n) could have been inserted at some point( sounds
funny but these things do come up.
Normally the suspect list in java is quite short but it may take a while to track down without some tools.
If you can get the symptom better defined the suspect list will probably be easy to sort.
11-18-2008 08:31 AM