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

[Jörg F . Wittenberger]

On Oct 22 2011, Felix wrote:

> From: Jörg F. Wittenberger <address@hidden>
> > Now I wonder: as far as I understand C_mutate it will remember
> > all assignments where the assigned value in within the nursery.
>
> It will remember all assignments, later GC will make the (important) 
> distinction whether there is heap-to-nursery pointer.

I've got that.  I meant that it would remember assignments to catch
all those, which would be important (heap-to-nursery).
Sorry haven't tried to describe what it does obviously, but what
I understood it's purpose would be.

Though it would sometimes and sometimes not be called, since a check
might avoid the C_mutate when not needed.

> It might
> be an option to do the in-stack test directly inside C_mutate.
> I don't think it buys much, though.

The patch I attached to the other posting would just do that.
Plus it did so inline instead of calling a procedure for the
stack check.
And it pulled the in-stack and the immediate check before the
C_mutate call.

Which would save at least one procedure call per assignment
another one if the in-stack check failed
plus the processing at gc time.


Since you confirmed the background so far, I still wonder:

> > If true, than I don't understand why we allow the mutation_stack
> > to ever grow beyond the size of the nursery.

It's not the *nursery* size, but the heap size.

But otherwise the point of my posting was:

So far untested/unimplemented (I'd rather get that understanding
of the mutation stack before I continue here): If we would
check a mutation stack usage limit before the interrupt limit
and at least enforce a minor gc on excess, we might be able to
leave the interrupt handling at the begin of the C_reclaim
and still avoid running havoc.

Reasonable?

Best Regards

/Jörg