Stack switching, Active Objects and LLVM

Project Infrastructure LLVM Dev List Archives
1

[Apologies. This is a repost because the earlier post didn't have a subject heading and might have been missed by members]

Hello,

I wish to have lots of little stacks and be able to switch rapidly
between them. I could do CPS transformation but don't like the overhead of
creating gc'able continuation thunks and the copying from stack to heap.

I'd like to explore a no-copy approach by "merely" switching a few
registers, perhaps as an equivalent of the C-- "jump" instruction (as
opposed to call). In other words, if a function calls "pause()", I'd like
to freeze the stack and be able to resume the thread at some time, like
green threads but faster (one shouldn't have to save all registers
blindly). I would appreciate some pointers on what it take to do this in LLVM?

The context for the question is this: I'm building a java-like language
with GC & classes and message passing (no memory sharing) between active
objects. I would like to be able to have several object pools that are
preemptively scheduled, but within one pool, the objects are cooperatively
scheduled. I'd like to have a GC to take advantage of the fact that no
memory is shared. A linear type system ensures that references to objects
passed in messages are owned by only one active object at any time.

--sriram

Thanks much.

2

I wish to have lots of little stacks and be able to switch rapidly between them. I could do CPS transformation but don't like the overhead of creating gc'able continuation thunks and the copying from stack to heap.

ok

I'd like to explore a no-copy approach by "merely" switching a few registers, perhaps as an equivalent of the C-- "jump" instruction (as opposed to call). In other words, if a function calls "pause()", I'd like to freeze the stack and be able to resume the thread at some time, like green threads but faster (one shouldn't have to save all registers blindly). I would appreciate some pointers on what it take to do this in LLVM?

This sounds quite doable. There are two ways you can approach this.

If you don't care about portability, you can use standard inline asm to achieve this. This works if your front-end is willing to handle knowing what to generate for each target.

If you don't like this approach, you can add an llvm intrinsics, which is expanded by the code generator to the right code for the current target.

-Chris