On Oct 25 2011, Felix wrote:
Couldn't either the signal handler return to gc, or - my preferred
alternative - the minor gc run prior to the signal handler?
Would make chicken robust to the case at hand.
This sounds possible, but it will trigger a collection even in cases
where it is not
Couldn't either the signal handler return to gc, or - my preferred
alternative - the minor gc run prior to the signal handler?
Would make chicken robust to the case at hand.
This sounds possible, but it will trigger a collection even in cases
where it is not needed, that is, when C_reclaim 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
If I compile (maybe too much) with disable-interrupts
could this prevent a garbage collection to happen?
No - GC is independent of interrupt handling. Interrupts just
piggyback on the GC checking mechanism.
I'm attaching a diff against current git master.
This does NOT help with the
From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net
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
On Oct 24 2011, Felix wrote:
Running on that code it looks as if the optimization is not
that small.
So is performance the point of this patch? Because it is not
completely clear what this patch addresses. The mutation stack
only overflows if you avoid GC (which can be easily traced),
are you
On Oct 24 2011, Felix wrote:
From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net
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
On Oct 22 2011, Felix wrote:
From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net
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)
From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net
Subject: Re: [Chicken-hackers] Need help to understand C_mutate better.
Date: 21 Oct 2011 18:10:44 +0200
From that theory I've been working in trialerror mode again.
I added a (gc) call to the end of my SIGCHLD handler.
Guess what
Hi,
Trying to get a better understanding where C_mutate might
be called in a way it can end up growing the mutation_stack
beyond bounds, I found in runtime.c:
C_h_pair
C_h_vector
C_h_structure
C_h_list
Those appear to be obsolete. Or at least I can't find
any reference to them from the rest
On Oct 21 2011, Jörg F. Wittenberger wrote:
For the C_mutate, whoever has any wild guess how this
behaviour could come up, please help me with that one.
I wonder: C_mutate is (in runtime.c) sometimes used like this
if(C_in_stackp(x)) C_mutate(y,x); else y=x;
and sometimes the C_in_stackp()
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? 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
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
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
From that theory I've been working in trialerror mode again.
I added a (gc) call to the end of my SIGCHLD handler.
Guess what: It did not run into the first, almost-for-sure
case. Often enough to make me walk the dog waiting for the second
case: the laptop coming back from a longer suspension
Hi all,
this goes to both chicken-users and chicken-hackers.
I feel it's more appropriate to chicken-hackers,
but recently I bothered the users with help requests on the
issue - maybe it's useful to learn where this ends up.
The problem I ran into:
Much depending on optimisation being done or
16 matches
Mail list logo
