chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Need help to understand C_mutate better.


From: Felix
Subject: Re: [Chicken-hackers] Need help to understand C_mutate better.
Date: Mon, 24 Oct 2011 11:25:35 +0200 (CEST)

From: Jörg F. Wittenberger <address@hidden>
Subject: Re: [Chicken-hackers] Need help to understand C_mutate better.
Date: 21 Oct 2011 15:58:17 +0200

> On Oct 21 2011, Jörg F. Wittenberger wrote:
> 
>>>The mutation stack will
>>>grow until a garbage collection takes place, so if you
>>>invoke C_mutate in a C loop without giving GC a chance,
>>>the mutations will just add up.
> 
> Reading C_reclaim still without fully understanding how
> exactly is will interact with C_context_switch
> it appears to me that if there where always an interrupt
> pending (or at least too often) then chicken would
> dispatch to the interrupt handler, which will switch context.
> 
> I don't see how the C code would return to the (minor) gc.
> In handle_interrupt is even mentioned that it must not return.

It doesn't - the GC is aborted. Interrupt frequency may simply
not be too excessive or GC will not run. This means *really*
excessive, though. Excessively excessive, which might indicate
a design problem.

> 
> If the next signal arrives before the next gc run this would take
> the same path.  This way the mutation stack will grow.
> Slightly at first, but the larger it becomes, the longer it takes
> to relocate, thereby increasing the probability of yet another turn.

What rate of signals/interrupts would you expect for a heavily loaded
instance of your application? 

> Given that what I have to do to kickstart the excessive
> memory consumption it involves massive handling signals and i/o.

You can set "C_post_gc_hook" or "set-gc-report!" to enable debug
output which will show you if GC's take place. I will also add some
debug output for mutation-stack reallocation.


cheers,
felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]