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

[Jörg F . Wittenberger]

On Oct 21 2011, Felix wrote:

> > For the C_mutate, whoever has any wild guess how this
> > behaviour could come up, please help me with that one.
>
> Do you use C_mutate in C code?

Nowhere.

> 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.

If I compile (maybe too much) with disable-interrupts
could this prevent a garbage collection to happen?

But I doubt, because I see the programm working as expected
except for slowness and memory consumption.  This means
scheduling and i/o works.  The i/o is definately run
from code, which has interrupts enabled.

So far I found a horrible workaround: set C_enable_interrupts
to zero!  I'm afraid this works only, because I have some
modules compiled with disable-interrupts where I actually
want thread switches.  Within those there is a manual
check for interrupts.  I'm afraid in the workaround mode
this is why it's working at all (and not at the ARM).

> The stack-test you pointed out is just a small optimization, the
> mutation stack is needed to keep track of pointers in the heap that
> might point to data in the nursery (stack).  Adding these checks can
> avoid adding the mutation-stack entry sometimes. If GC takes place
> often enough (which it does in normal, compiled Scheme code), it is
> probably not too much of an overhead to just add the mutation-stack
> entry. 

I'm attaching a diff against current git master.

This does NOT help with the C_mutate issue I see.

It pull the simple tests first and inlines C_in_stackp .

Running on that code it looks as if the optimization is not
that small.

Note that I did not complete all of the C_h_* family, since
I'm afraid those are really obsolete.

/Jörg

instackp.diff
Description: instackp.diff