Time to reconsider m:n or green threading options?

[Charles Oliver Nutter]

Patrick Wright wrote:
> Looks like the original threading model in the Sun JVM was 1:n threading
> 
> http://en.wikipedia.org/wiki/Green_threads

That fits my memory as well.

> Most of what I found on a quick Google seemed to confirm that article.
> Apparently "green threads", as implemented earlier in the Sun JVMs,
> had one OS thread, running the VM, which would then manage multiple
> green threads. There are apparently different mechanisms for deciding
> when to switch between the green threads. Big drawback appears to have
> been a) blocking I/O could cause the whole VM to wait and b) there's
> only 1 OS thread underneath, meaning no use of multiple processors.
> 
> Apparently, the Blackdown JVM used to allow for green or native
> threading selection.
> 
> I didn't find any references to m:n threading regarding green threads,
> though. I suspect the terminology will get in the way in this
> discussion.

Yes, my memory is that Blackdown had the green/native split and on some 
platforms (freebsd for example) there was only green.

> Actors, as implemented in Scala, allow many Actor instances to be
> scheduled from one thread pool, which means the number of Actors can
> be many many times the number of threads in use; but that is
> implemented as a library. Kilim has impressive benchmarks but is using
> some annotations and some complex bytecode manipulation to works its
> magic. Both of these work with the current JVM architecture.

They work but they're limited in scope. If you call into a library that 
has not been manipulated, you either need to manually unroll stack, push 
that call off to another thread, or something else. Same goes for Rife. 
That sort of bytecode manipulation is very clever (i.e. very very 
clever, the kind of clever I really like), but it's not a general enough 
solution.

> What would you want the JVM to provide that it doesn't provide currently?

I would want the JVM to provide the current thread APIs but potentially 
backed by a smaller number of native threads. I want to be able to spin 
up 10k or 100k java.lang.Thread instances :)

- Charlie