Re[2]: [Gc] Problems with GC performance using gcj

Ivan Maidanski ivmai at mail.ru
Mon Jan 17 12:38:50 PST 2011


Hi,

To control GC_use_entire_heap value, I've added a test of GC_USE_ENTIRE_HEAP macro and environment variable (for convenience).

Regards.

Thu, 13 Jan 2011 14:20:04 -0500 "Ben Keppler" <bkeppler at tridentms.com>:

> Hi Bruce,
> 
> A large portion of our churn occurs as a result of network packet traffic, so
> lots of byte arrays, strings, etc. that don't, in fact, need to be scanned. 
> The interesting thing is that we went through a several day thrash to create
> pools of network packets to reduce heap thrash.  It made a difference when
> running under the JVM, but not when compiled to native code with GCJ (implying
> the use of the Boehm GC).  It appears GCJ uses GC_malloc_atomic() at the very
> least for Strings.  I didn't do a complete analysis to prove it does so for
> byte arrays as well, but one assumes that since they were aware of the issue
> for Strings, they probably were for byte arrays as well.
> 
> One last factor to consider is that gcj appears to be using version 6.6 of the
> Boehm GC.  I don't know how substantial the changes are in the more recent
> versions or whether they could have an impact on the pause times.  Perhaps you
> could shed light on that.
> 
> Thank you for your help.
> 
> Best Regards,
> 
> Ben Keppler, Software Engineer
> Trident Micro Systems
> E-mail: bkeppler at tridentms.com * Voice: 828.684.7474 * Fax: 828.684.7874
> 
> ________________________________________
> From: bruce.hoult at gmail.com [mailto:bruce.hoult at gmail.com] On Behalf Of Bruce
> Hoult
> Sent: Tuesday, January 11, 2011 8:19 PM
> To: Ben Keppler
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc] Problems with GC performance using gcj
> 
> On Sat, Jan 8, 2011 at 4:16 AM, Ben Keppler <bkeppler at tridentms.com> wrote:
> Alternatively, are there settings on the Boehm GC that might relieve our
> problems?  I would appreciate any information you could provide.
> 
> You also don't say what settings you're using now, or give any hint about the
> characteristics of your application.
> 
> Things that can often make a big difference to overall throughput (but not
> pause times) at the expense of heap size include:
> 
>   GC_use_entire_heap = 1;
>   GC_free_space_divisor = 2;
> 
> Things that can make a big difference to pause times
> include GC_all_interior_pointers = 0 and using GC_malloc_atomic() instead of
> GC_malloc() as much as possible, especially if a large fraction of your live
> data is strings, sounds, images or the like that don't need to be scanned for
> pointers.
> 
> I don't know whether GCJ is using GC_malloc_atomic() for String, StringBuffer,
> byte[], short[], int[]. long[], float[], double[] but it certainly should be.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 3095 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20110117/a21020fa/attachment.obj


More information about the Gc mailing list