[Gc] 6.2 to 6.4 change?

Boehm, Hans hans.boehm at hp.com
Fri Apr 22 14:47:58 PDT 2005

It's surprising to me.  I haven't seen such behavior.

The current heap expansion heuristic is not
as robust as I would like, so it's not mathematically impossible that
this would happen for no good reason.  (This should be fixed in the
experimental 7.0 tree.  You should be able to work around it with a
smaller free_space_divisor.)  But I'm definitely suspicious that
beyond this is going wrong here.

What's your platform?  There were some major changes for Windows,
but I would have expected them to have the opposite effect, if any.

It would be good to run both versions with the GC_DUMP_REGULARLY
environment variable defined, and see if there are any differences
in the sizes of static roots.  If not, the next step is to 
place a breakpoint in GC_expand_hp_inner in the 6.4 version, run it
until one of the last heap expansions, and then try to understand
why it's being called in spite of the mostly empty heap.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Nikhil Swamy
> Sent: Friday, April 22, 2005 11:43 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] 6.2 to 6.4 change?
> Hi,
> I just switched from gc6.2.4-alpha to gc6.4 and have noticed 
> a pretty dramatic change in behavior. I'm running the same 
> benchmark with only a change in the gc version, with the same 
> configure parameters on both gc versions. Here's is what I notice:
> The reserved space size with 6.2.4 grows upto 750KB, there 
> are around 950 collections, and this takes around 800 clock 
> units to run. Running with 6.4 the reserved space grows to 
> about 20MB, there are only about 110 collections, and it runs 
> in about 450 clock units. In both cases, each collection 
> reclaims almost all of the heap.
> This looks like an obvious trading of space for time. Is this 
> behavior expected? Nothing in the "recent_changes" file 
> seemed to me to indicate that there's been a change of this 
> nature. If this is indeed expected behavior, is there some 
> way to control the growth strategy other than by tweaking the 
> free space divisor?
> I appreciate any insight you might be able to provide.
> Thanks,
> Nikhil
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list