Stack swapping

Project Infrastructure LLVM Dev List Archives
1

Thanks to help in a previous thread, I now have a working LLVM codegen
for the MLton compiler. Currently the stack is managed explicitly on
the heap. This way the LLVM codegen re-uses the runtime layout of the
other codegens, simplifying the initial porting effort.

In the next phase I plan to switch to using LLVM to manage the stack,
but there is a sticking point: MLton switches stacks. It does this on
calls to C (which use the primordial C stack) and also between
application-level threads. ML stacks automatically expand when a limit
check triggers garbage collection. I understand that getting this to
work will require some non-portable glue on my part.

I have a number of ideas on how to get this to work, but also assume
that MLton isn't the first project which swaps stacks. What's the
established best practice for managing multiple stacks under LLVM?

2

* Wesley W. Terpstra:

I have a number of ideas on how to get this to work, but also assume
that MLton isn't the first project which swaps stacks. What's the
established best practice for managing multiple stacks under LLVM?

I think this isn't really a LLVM question. For most platform ABIs,
LLVM code is compatible with stack switching because historically,
this was how multi-threading was implemented (and pthreads looks a lot
like stack switching, too), and there is quite a bit of software
around which does it (the PowerDNS recursor, Lua with the Coco patches
and LuaJIT).

The Coco patches for Lua have some discussion about portability and
implementation choices: <http://luajit.org/coco.html&gt;