[Gc] stack problem

Boehm, Hans hans.boehm at hp.com
Mon Sep 29 18:14:41 PDT 2008


Could you try this with 7.1?  There was a significant performance bug fix shortly before that release.  I'm not sure that's the issue here, but it would be good to preclude that.

If that doesn't work, see below:

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Romano Tenca
> Sent: Monday, September 29, 2008 5:21 AM
> To: Gc at napali.hpl.hp.com
> Subject: [Gc] stack problem
>
> I use GC in a program which sometime call a recursive
> function which consume a large C stack.
>
> After the use of this function, when the C stack is back to a
> normal size, GC allocations and recycles becomes a lot more slow.
>
> To give an idea, here it is the output of a test program
> which reports the time used by  10 GC_gcollect() calls inside
> a recursive function:
>
> After 0 recursions 10 GC_gcollect() time is: 0.03125 After
> 5000 recursions 10 GC_gcollect() time is: 0.203125 After
> 10000 recursions 10 GC_gcollect() time is: 0.59375 After
> 15000 recursions 10 GC_gcollect() time is: 1.1875 After 20000
> recursions 10 GC_gcollect() time is: 2.015625 After 25000
> recursions 10 GC_gcollect() time is: 3.0625
>
> Here are some heap values after the recursive function returns:
>
> Heap: 5505024 Free: 4296704 Used: 1208320 Collections: 61
Is the issue just that you're starting out with nothing in the heap?  The final times in the two cases don't seem that different?  I agree that the absolute times seem way too long for the heap size, so that's probably not it.

It would be interesting to profile the two cases.

GC_push_stack_for() contains some debugging code that prints out how much of the stack is actually getting pushed.  It's normally not compiled in, but it would be easy to turn on for an experiment.  There is fallback code that pushes the whole stack, but that shouldn't be getting used.  And it should generate warnings if it is used.

Hans
>
> Now i call again the recursive function:
>
> After 0 recursions 10 GC_gcollect() time is: 2.984375 After
> 5000 recursions 10 GC_gcollect() time is: 3.015625 After
> 10000 recursions 10 GC_gcollect() time is: 3.0625 After 15000
> recursions 10 GC_gcollect() time is: 3.09375 After 20000
> recursions 10 GC_gcollect() time is: 3.140625 After 25000
> recursions 10 GC_gcollect() time is: 3.1875
>
> Here are some heap values after the recursive function returns
>
> Heap: 5505024 Free: 4288512 Used: 1216512 Collections: 121
>
> As you can see the Heap and Used memory is almost the same,
> but the time of GC_collect are very different. It seems to me
> that the GC looks at all the stack, also the not more used one.
>
> I do not know if this is a bug, but there is a way to tell GC
> to scan only the used stack?
>
> I use version 70a with thread_local_alloc and UNMAP under XP.
> Tests are done with only the main thread running.
>
>
> Romano Paolo Tenca
>
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>



More information about the Gc mailing list