Email list hosting service & mailing list manager

Couple things... felix (22 Dec 2003 17:51 UTC)
(missing)
(missing)
(missing)
Re: Couple things... felix (24 Dec 2003 11:43 UTC)
Re: Couple things... tb@xxxxxx (24 Dec 2003 23:30 UTC)
Re: Couple things... Michael Sperber (27 Dec 2003 18:46 UTC)
Re: Couple things... felix (24 Dec 2003 12:40 UTC)
Re: Couple things... Michael Sperber (26 Dec 2003 15:16 UTC)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
Re: Couple things... felix (04 Jan 2004 18:51 UTC)
Re: Couple things... Tom Lord (04 Jan 2004 22:13 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:18 UTC)
Re: Couple things... Tom Lord (05 Jan 2004 21:53 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:19 UTC)
Re: Couple things... felix (04 Jan 2004 18:42 UTC)
(missing)
(missing)
(missing)
Re: Strings/chars Tom Lord (24 Dec 2003 04:47 UTC)
(missing)
Re: Couple things... felix (24 Dec 2003 12:01 UTC)
Re: Couple things... Jim Blandy (24 Dec 2003 16:29 UTC)

Re: Couple things... Jim Blandy 24 Dec 2003 16:25 UTC

felix <xxxxxx@call-with-current-continuation.org> writes:
> Chicken for example uses the C-stack as the first generation of
> a generational GC scheme (as described in Henry Baker's Cheney-on-
> the-MTA paper). Calling C from Scheme is no problem, if the code
> returns properly, but a callback/GC would possibly invalidate the portion
> of the stack below the currently pending C stack-frame, and uncontrolled
> shrinking of the nursery would quickly result in problems. To prevent
> this, the nursery (1st gen. / C-stack) has to be resized, by pulling
> out live data (and cleaning up the nursery) before calling the C
> code, and then setting the "watermark" that marks the lower end of the
> stack. One method would be to simply disallow callbacks (as Baker
> proposes in his paper), but we don't want that, of course...
> Another issue is threads: the blocking behaviour mentioned in SRFI-50
> on returning from callbacks would not have to be checked, if it is
> known that the invocation of C from Scheme has no chance of calling
> back into Scheme.

Okay, I think I see.

When using Cheney-on-the-MTA, collection entails popping off the
entire portion of the C stack you're using for your nursery, after
scavenging all the live objects out of it.  Any active C frame is a
live object, but you don't have enough information to scavenge those,
so your nursery must always be free of active C frames.  (Otherwise
you'd have to put off collecting the portion below the youngest active
C frame until it exits, and you have no idea how long they'll stick
around...)

So your C stack is divided into two portions:
- at the older end, you have active C frames, and
- at the younger end, you have your nursery.

The "watermark" that you mentioned indicates the boundary between
these two portions.

So, to invoke a C function that might perform callbacks, you must
collect and pop your nursery, to allow you to place that call's frame
at the (now exposed) younger end of the C frame area.  In contrast, to
call a C function that you know will not perform callbacks, none of
that is necessary; you just make the call on top of whatever nursery
you've got.

It seems to me that the called function also must not allocate any
heap objects.  Or do you simply allocate them directly in the next
older generation, bypassing the nursery altogether?