Strange Performance Tests

Wed Jul 10 13:53:00 GMT 2002

I assume this is gcc 3.1?
The decision about when to collect is actually fairly complex. It looks like something here is going wrong in the default case.
Can you determine whether GC_max_large_allocd_bytes keeps growing or stabilizes? Is there a phase during which you allocate primarily large objects?
The relevant code here is probably near the beginning of GC_allochblk_nth. This is in the heart of the page or chunk level memory allocator. It decides whether it should split a large available heap block in order to satisfy a smaller request, or risk failing and trigger a GC earlier than otherwise necessary. Splitting the block risks not being able to allocate a subsequent large request. Collecting earlier is much better for fragmentation, but risks higher GC overhead. To make a reasonable decision it remembers how much memory you previously used for very large objects (GC_max_large_allocd_bytes). If it believes you needed many large objects in the past, it tends to collect earlier.
Explicitly requesting a large heap also affects this decision. If you ask for N MB, it assumes that it shouldn't collect before you've actually used up those N MB. Otherwise the initial heap size wouldn't have much impact on collection frequency. Thus it's not too surprising (well, to me, anyway) that setting GC_INITIAL_HEAP_SIZE improves matters. (Setting GC_use_entire_heap has a more direct effect.)
Overall, my impression is that the performance of the GC relative to Hotspot varies depending on the application. I don't have real comparisons, but anecdotal evidence and other peoples measurements of other implementations of similar algorithms (cf. http://www.research.ibm.com/people/d/dfb/papers/Attanasio01Comparative.pdf) suggest that our collector does well on something like SPECjbb with a reasonably sized heap, i.e. not the >2GB runs you typically find on specbench.org. (Quality of generated code for SPECjbb seems to be a different issue. Real multithreaded profiling support for Linux would be nice.) The HotSpot collector probably wins for typical client code, which apprently benefits more from a generational collector.
You can get a bit of information about what the collector is doing by defining the environment variable GC_PRINT_STATS.
Hans
> -----Original Message-----
> From: Lars Andersen [mailto:lars@rimfaxe.com]
> Sent: Wednesday, July 10, 2002 1:09 PM
> To: java@gcc.gnu.org
> Cc: Michael Smith
> Subject: Re: Strange Performance Tests
>>> On Wed, 2002年07月10日 at 21:48, Michael Smith wrote:
> > Lars Andersen wrote:
> > > On Wed, 2002年07月10日 at 21:21, Andrew Pinski wrote:
> > > 
> > >>I think the spikes in both are the gc (garbage collector) running.
> > >>The gc for gcj is boehm's which might be slower than the one 
> > >>used by Sun.
> > >>
> > >>Thanks,
> > >>Andrew Pinski
> > > 
>> > 
> > try increasing the initial heap size.
> > 
> > For gcj,
> > export GC_INITIAL_HEAP_SIZE=<size>
> > 
> > For the jdk,
> > java -Xmx<size>
> > 
> > If the spikes occur less frequently, but have longer times, 
> that would 
> > be indicative of the GC.
> > 
>>> OK, the plot thickens!
>> I tried with following settings of GC_INITIAL_HEAP_SIZE:
>> 16000000, 32000000 and 128000000
>> GCJ now runs as fast or faster than SUN jdk1.4 regardless of what
> initial heapsize I choose!
>> Apparently, just setting the initial heap size to something more than
> doubles the performance of my app!!!
>> /Lars Andersen
>>>>