views:

798

answers:

3

I was wondering if it is possible to tweak the way garbage collector works on JavaMe in order to improve performance somehow(may reducing the number of passages)? I´ve seen some articles about it, but mostly directed Java SE and most of them says GC is highly dependant on the maker. How much would that be.

+1  A: 

I don't see any possible way to tweak the garbage collection behavior in J2ME.

If you have problems with pauses induced by garbage collections, you have to do two things:

  • Reduce the garbage that your program produces, by re-using objects, and avoid costly things like string concatenations (use StringBuffer instead)
  • Use System.gc() to force garbage collection when a little freeze doesn't matter (for example, during the "loading" screen of a game), to reduce the odds that the collector process is triggered when it's annoying.
ckarmann
FYI, There is no `System.gc()` in any of the standard JME APIs...
Ken Gentle
I may be wrong but it is defined in JSR 30 (CLDC) http://java.sun.com/javame/reference/apis/jsr030/and also in JSR 218 (CDC) http://java.sun.com/javame/reference/apis/jsr218/And it is defined as the equivalent of Runtime.getRuntime().gc()But maybe we are not talking about the same thing ...
ckarmann
Yeah, there is definitely a System.gc() in J2ME. What is going on in this question? A couple of blatantly wrong comments.
Fostah
+3  A: 

When the garbage collector is triggered is largely a mistery unless you have first hand knowledge of how the particular VM your application is running on was implemented and exactly how it was configured and customized for the specific phone you are using.

Calling java.lang.System.gc() is no guarantee that the garbage collector is triggered. It usually merely increases the probablility of the VM launching garbage collection very soon.

I have found that calling System.gc() 3 times consecutively in the same Thread but from 3 different methods tends to work reasonably well.

There are many ways to work around ineficiencies in the JavaME standard API implementations in order to reduce the amount of garbage you generate:

  • Extend ByteArrayOutputStream so you don't create a copy of the byte array when you want to access the data.

  • avoid calling StringBuffer.getChars() and StringBuffer.toString(). make your code work with StringBuffer offsets and lengths instead.

  • turn local buffers (byte[], StringBuffer...) into instance or static variables (and protect them with synchronized). Obviously, there is an overhead to doing this but it can prevent your application from freezing due to garbage collection too often.

  • Extend StringBuffer to avoid switching back and forth between String and StringBuffer : implement append(String, offset, length), parseInt(int), indexOf(String, index), replace(offset, StringBuffer, offset, length)...

...

QuickRecipesOnSymbianOS
Actually Java ME doesn´t have StringBuffer since is based on older versions of Java SE (1.4 or less I think).
Decio Lira
Java ME certainly does have a StringBuffer class. It's in the java.lang package.
Fostah
Sorry, I meant to say StringBuilder :)
Decio Lira
A: 

Thanks for all the input people. I´ve seen it´s not possible to tweak the GC for Java Me capable devices. At least not in any easy or usefull way. I´ll leave this question open anyway, in case this scenario changes somehow in the time being. :)

Decio Lira