Guile and ucontext

Guile and ucontext

[Fredrik Tolf]

Hi list,

I'd really like to use Guile in a program I'm writing, but I'm having a
problem in that I'm using the ucontext calls rather heavily to run a
great amount of light-weight threads (in only one pthread, that is), and
it seems that Guile doesn't exactly thrive in that environment.

>From what I can tell from Guile's threads.c, Guile will just record the
top and bottom of a single stack per pthread, and since I'm switching
stack pointer between the original stack at the top of the process to
heap-allocated stacks, it would try to mark data words from almost the
entire process space when GC'ing.

Is this correct, or is it perhaps possible to make Guile understand my
stack switching as it is? Or is it, perhaps, possible to turn off
marking of words on the stack? (I won't be keeping very many SCM
pointers there that aren't reachable from scheme variables anyway, and
if I do, I think I can protect them manually) If it isn't, I guess I'll
have to patch Guile to cope with multiple stacks, but I'd rather spare
myself that work unless it's necessary.

Thanks for reading!

Fredrik Tolf

Re: Guile and ucontext

[Neil Jerram]

Fredrik Tolf <fredrik@dolda2000.com> writes:

> Hi list,

Hi Fredrik,

> I'd really like to use Guile in a program I'm writing, but I'm having a
> problem in that I'm using the ucontext calls rather heavily to run a
> great amount of light-weight threads (in only one pthread, that is), and
> it seems that Guile doesn't exactly thrive in that environment.

Interesting problem...

Two vaguely encouraging initial thoughts:

1. On ia64, Guile's exception and continuation logic is already
implemented using setcontext() and getcontext().  (This is done via
some strange redefinitions of setjmp and longjmp; see __scm.h.)  If
you follow through that code, and the things like stack saving and
copying that are done in conjunction with those calls, it may give you
a clear idea of what would be needed to support more general ucontext
switching.

2. If you are happy to be really on the bleeding edge, you could try
using the "bdw-gc-static-alloc" or "boehm-demers-weiser-gc" branch
from Git.  Those branches use the Boehm GC library instead of Guile's
own GC code, and Boehm GC may work better with ucontext switches.

>>From what I can tell from Guile's threads.c, Guile will just record the
> top and bottom of a single stack per pthread, and since I'm switching
> stack pointer between the original stack at the top of the process to
> heap-allocated stacks, it would try to mark data words from almost the
> entire process space when GC'ing.

I'm afraid I don't understand this.  Are you changing the whole stack
of an existing thread?

> Is this correct, or is it perhaps possible to make Guile understand my
> stack switching as it is? Or is it, perhaps, possible to turn off
> marking of words on the stack?

Not by build or runtime configuration, no.  (Stack marking is a pretty
fundamental concept.)

> (I won't be keeping very many SCM pointers there that aren't
> reachable from scheme variables anyway, and if I do, I think I can
> protect them manually) If it isn't, I guess I'll have to patch Guile
> to cope with multiple stacks, but I'd rather spare myself that work
> unless it's necessary.

Dive in!  If you grep for "scm_mark_locations", that will show you all
of the memory regions that get scanned for GC, including thread
stacks.

Regards,
        Neil

Re: Guile and ucontext

[Fredrik Tolf]

On Sat, 2009-05-16 at 13:07 +0100, Neil Jerram wrote:
> 1. On ia64, Guile's exception and continuation logic is already
> implemented using setcontext() and getcontext().  (This is done via
> some strange redefinitions of setjmp and longjmp; see __scm.h.)  If
> you follow through that code, and the things like stack saving and
> copying that are done in conjunction with those calls, it may give you
> a clear idea of what would be needed to support more general ucontext
> switching.

Indeed? I'll look into that. Thank you!

> >>From what I can tell from Guile's threads.c, Guile will just record the
> > top and bottom of a single stack per pthread, and since I'm switching
> > stack pointer between the original stack at the top of the process to
> > heap-allocated stacks, it would try to mark data words from almost the
> > entire process space when GC'ing.
> 
> I'm afraid I don't understand this.  Are you changing the whole stack
> of an existing thread?

Well, yes. It is hard for me to think of how I would switch contexts
without switching stacks as well. :)

Fredrik Tolf

Re: Guile and ucontext

[Neil Jerram]

Fredrik Tolf <fredrik@dolda2000.com> writes:

>> >>From what I can tell from Guile's threads.c, Guile will just record the
>> > top and bottom of a single stack per pthread, and since I'm switching
>> > stack pointer between the original stack at the top of the process to
>> > heap-allocated stacks, it would try to mark data words from almost the
>> > entire process space when GC'ing.
>> 
>> I'm afraid I don't understand this.  Are you changing the whole stack
>> of an existing thread?
>
> Well, yes. It is hard for me to think of how I would switch contexts
> without switching stacks as well. :)

Sure, I understand that.  But I was struggling to understand what you
said about "try to mark data words from almost the entire process
space when GC'ing".  Guile knows the top and bottom of every stack
that is in Guile mode, and marks from top..bottom of each stack; never
from the top of one stack to the bottom of another one.  So I don't
see how it could arise that Guile would try to mark almost the entire
process space.  Can you explain that further?

Regards,
        Neil

Re: Guile and ucontext

[Fredrik Tolf]

On Sat, 2009-05-23 at 10:58 +0100, Neil Jerram wrote:
> Fredrik Tolf <fredrik@dolda2000.com> writes:
> 
> >> >>From what I can tell from Guile's threads.c, Guile will just record the
> >> > top and bottom of a single stack per pthread, and since I'm switching
> >> > stack pointer between the original stack at the top of the process to
> >> > heap-allocated stacks, it would try to mark data words from almost the
> >> > entire process space when GC'ing.
> >> 
> >> I'm afraid I don't understand this.  Are you changing the whole stack
> >> of an existing thread?
> >
> > Well, yes. It is hard for me to think of how I would switch contexts
> > without switching stacks as well. :)
> 
> Sure, I understand that.  But I was struggling to understand what you
> said about "try to mark data words from almost the entire process
> space when GC'ing".  Guile knows the top and bottom of every stack
> that is in Guile mode, and marks from top..bottom of each stack; never
> from the top of one stack to the bottom of another one.  So I don't
> see how it could arise that Guile would try to mark almost the entire
> process space.  Can you explain that further?

Oh, I see. I thought it was weird. :)

Well, unless I have grossly misunderstood what I read in threads.[ch],
Guile records the base and top of the stack per POSIX thread, and
doesn't ever change the base unless it is found at a higher address than
before. Thus, to take an example:

Say that I first run a function in Guile mode when the stack pointer is
somewhere in the ELF-loader allocated stack; say at 0xBEEFBABE. Guile
records that address as the stack base. Then I switch to some
heap-allocated stack and run some Guile code. Now, my stack pointer
might be at, say, 0x0F00FACE. The previously recorded base address won't
change, but that stack will be used as the top of the stack. When the
Guile's GC runs, it would, then, try to mark all words from the stack
top to the stack base: that is, from 0x0F00FACE to 0xBEEFBABE.

Almost the entire process space, in other words (and probably with lots
of unmapped space in it).

I hope that makes my point clearer.

Fredrik Tolf

Re: Guile and ucontext

[Neil Jerram]

Fredrik Tolf <fredrik@dolda2000.com> writes:

> Well, unless I have grossly misunderstood what I read in threads.[ch],
> Guile records the base and top of the stack per POSIX thread, and
> doesn't ever change the base unless it is found at a higher address than
> before.

Correct.

> Thus, to take an example:
>
> Say that I first run a function in Guile mode when the stack pointer is
> somewhere in the ELF-loader allocated stack; say at 0xBEEFBABE. Guile
> records that address as the stack base. Then I switch to some
> heap-allocated stack and run some Guile code. Now, my stack pointer
> might be at, say, 0x0F00FACE.

Ah, I see, so the stack base is changing for the same thread.  That is
something that never happens in Guile at the moment, even when playing
with continuations.  So we're into new territory here.

> The previously recorded base address won't
> change, but that stack will be used as the top of the stack. When the
> Guile's GC runs, it would, then, try to mark all words from the stack
> top to the stack base: that is, from 0x0F00FACE to 0xBEEFBABE.
>
> Almost the entire process space, in other words (and probably with lots
> of unmapped space in it).
>
> I hope that makes my point clearer.

Yes, it's clear now, thanks for explaining.

In principle maybe all that is needed to handle this is to

- update the affected thread's stack base when the context is
  switched

- save off the top and bottom of the previous stack (if it may be
  reinstated again later), so that the GC can scan it - this would be
  similar to how a continuation's stack is stored in the continuation
  object and scanned by the GC.

I hope that helps.  Do you plan to have a go at these changes?

Regards,
        Neil