Re: [Gc] Problems with GC performance using gcj
ivmai at mail.ru
Sat Jan 8 23:33:49 PST 2011
Fri, 7 Jan 2011 10:16:56 -0500 "Ben Keppler" <bkeppler at tridentms.com>:
> NOTE: This question was also posted on the gcj mailing list.
> We are using gcj for a time sensitive application. One of the
> requirements of the application is that messages be transmitted within a
> 60ms timeframe. Unfortunately, the Boehm GC used in gcj is not
> generational and thus every collection is of the "stop the world"
> variety. We are observing (using "GC_PRINT_STATS") regular collections
> that stop the world for periods in the 400ms range. This is a problem
> for us.
> The comments I have found on the "incremental" setting for the Boehm GC
> indicate that it doesn't work with gcj, so that would not appear to be
> an option. My question is, are there other GC options (perhaps a
> generational garbage collector) available for gcj? My research has
> revealed none other than TinyGC, an option that would exacerbate rather
> than relieve our problems. Alternatively, are there settings on the
> Boehm GC that might relieve our problems? I would appreciate any
> information you could provide.
AFAIK, there is no alternative to BDWGC for gcj. So, the only thing for you (unless you decide to switch to some real-time JVM) is to play with GC tuning.
I haven't seen that comments about incremental mode in gcj, but the true is that gcj uses previous BoehmGC major release and I don't know whether the bugs fixed in the current BoehmGC release has been also fixed in libgc of gcj.
You are right about TinyGC which I wrote to be a replacement for BoehmGC - my intention was small code (as well as the possibility to quickly replace BoehmGC for testing purposes) not speed.
> Ben Keppler, Software Engineer
> E-mail: bkeppler at tridentms.com * Voice: 828.684.7474 * Fax: 828.684.7874
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 2364 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20110109/b304e546/attachment.gif
More information about the Gc