Time to reconsider m:n or green threading options?
Charles Oliver Nutter
charles.nutter at sun.com
Sat Jun 21 04:58:26 PDT 2008
Patrick Wright wrote:
> Looks like the original threading model in the Sun JVM was 1:n threading
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
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
> 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 :)
More information about the mlvm-dev