user-space threads

[Adam Megacz <adam at megacz dot com>]

Is it possible to implement gcj's threading entirely in userspace,
using nonblocking I/O and alarm()?

One of the reasons that a lot of server programs are moving towards
event-loop, nonblocking-io and away from thread-per-request is that
threads are "expensive".  Most of this "expensiveness" is just a
result of OS implementors not thinking that people would ever want to
form 10,000 threads -- so often they'll use data structures like
linked lists of threads and perform a linear scan through the list for
some operations.

It turns out that there's nothing inherently expensive about threads
except that each thread gets its own stack on a seperate page, which
cause memory cache thrash.  I'm investigating a technique for getting
threads to *share* a stack -- interleaving the stack frames from
different processes on a single page.  Actually, I'd probably have a
few stacks, each with a fixed frame size (8 byte, 32 byte, 64 byte,
etc).  Java turns out to be an ideal language for this, because its
stack frames are really tiny (no stackvars).

Anyways, userspace threads would be a straightforward way to implement
this.  They'd also be useful for platforms that have alarm() but don't
have threads (lots of embedded platforms).

Does the gc make any assumptions about threading that would break if I
used this technique?

  - a

-- 
"Through your rags I see your vanity"  -- Socrates