Any multi-threaded interpreters?

Are there any thread-safe language interpreters out there that run multi-threaded code? Python uses a global interpreter lock to run threads one at a time, though it does some meager preemption. I think I read somewhere that Erlang is actually single-threaded, though it manages zillions of Erlang "processes". Is that still true?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Working on One

The interpretter for my (as of yet unreleased) language Rhope is multi-threaded. I haven't done enough testing to say whether or not it can actually run parallel problems faster with multiple threads. The only real benchmark I've run is naive recursive fibonacci, but that would appear to be memory bandwidth bound in my language currently and actually runs more slowly when the threads are allowed to run on multiple cores. The language doesn't have any explicit threading though. The semantics of the language allow the interpretter to run independent statements in parallel.

I believe Erlang's "processes" are light-weight user level processes, but these processes can be split up amongst kernel threads to take advantage of multi-core/multi-processor machines. Each individual process will execute in a single thread, but an Erlang application as a whole can operate on multiple kernel threads. At least that's how I think it works. I haven't had a chance to use Erlang yet so I'm still a bit fuzzy on certain aspects of the language.

By "multi-threaded"

do you mean "utilizing multiple kernel threads"?

Erlang, mentioned above. IIRC, Erlang spawns as many kernel threads as there are CPUs, and then allocates the many Erlang processes among that fixed number of threads.

Most JVMs as well; other than early "green threads" implementations, a JVM will typically map each Java thread onto a native kernel thread. (Are there any JVMs that utilize multiple threads, but map more than one Java thread onto a kernel thread)?

Beyond those, I dunno.

Are there any JVMs that

Are there any JVMs that utilize multiple threads, but map more than one Java thread onto a kernel thread

Not intrinsically so, that I'm aware of, except that you will obviously get M:N threads if the JVM is using native threads, and the platform's native threads are M:N (e.g. on Solaris < 9).

Scheme

I think MzScheme has the capability to run multi-threaded code.
According to the manual,

MzScheme supports multiple threads of control within a program. Threads are implemented for all operating systems, even when the operating system does not provide primitive thread support.

from Chapter 7 of the MzScheme manual.

MzScheme wins again

The second part of that quote implies threads are implemented in Scheme, probably via continuations. However, this link says MzScheme can be compiled to use OS threads on a few OSes. http://www.cs.rice.edu/CS/PLT/packages/doc/insidemz/node7.htm

It looks like Erlang started using multiple OS threads just last year. Before that you had to run multiple instances of the Erlang runtime.

MzScheme doesn't support multi-processors

The docs I linked to were for a very old version of MzScheme.

any particular interest?

Pinku Surana: Are there any thread-safe language interpreters out there that run multi-threaded code?

Probably, but I'd expect only in high end implementations because making code thread-safe is involved. (I do that a lot, so I know a fair amount about it, but I don't have a thread-safe interpreter myself yet for reference.) Pavone's and Johnson's remarks sound exactly correct. I expect JavaScript ought to end up thread-safe soon if it isn't already.

It's easier to answer such questions when you cite motivation, since folks can address motivation as well as just question asked. It's do-able but problematic since you normally need to choose which places are not thread-safe where synchronization is needed, unless you have a model like Erlang where safety is moot when there's no shared mutable state to protect.

Pinku Surana: Python uses a global interpreter lock to run threads one at a time, though it does some meager preemption.

Likely still true since removing that constraint is mentioned often. If someone writes a thread-safe interpreter for language Foo, then implements Python on top of that or on top of the same common runtime, the result could be thread-safe Python. (It's possible some semantics of Python might require races on shared state that are hard to fix -- I don't know.)

Pinku Surana: I think I read somewhere that Erlang is actually single-threaded, though it manages zillions of Erlang "processes". Is that still true?

Erlang should be running a large number of "green threads" as lightweight processes per kernel thread, but with multiple threads and/or multiple processes, so the result is Erlang running with thread-safe concurrent code in the same system. It should still be true that some "green threads" might have no need of protection from pre-emptive threads, so they run like they are single-threaded despite keeping company with other threads. (I'm only familiar with cursory Erlang details, so I could easily be off.)

Neko

Neko http://nekovm.org is a Virtual Machine which can run several kernel threads. The same code can be shared among threads, but you have to be careful to use some locks if you want to modify some data structures concurently.

Are objects thread safe?

I've looked at this page:

http://nekovm.org/doc/mt

and it's not clear whether the internal dictionary of an object is threadsafe or not, which is the central question. For instance, is it safe to call a method from thread A while adding a field from thread B? On a hashtable, without locking this is not possible (because it might be resized).

Java

Java is multi-threaded, and if you disable the JIT compiler, then it becomes interpreted.

You can do this from the command-line like this:

java -Xjava.compiler=NONE ...

Petite Chez Scheme

Petite Chez is a multi-threaded Scheme interpreter with good performance for an interpreter:
     http://scheme.com/
I use Chez Scheme (the full version) for parallel applications related to stream processing. I've also been playing around with parallelizing my whole-program compiler for the DSL I'm working on (Regiment / WaveScript) using Cilk-style work-stealing techniques.
What Chez provides is basically a straight forward interface to pthreads. I've been running it on shared memory machines with as many as 16 cores. But unfortunately Chez's collector still stops all threads to collect.

Slower multithread performance

Unfortunately, the multithreaded version is documented as having higher overhead than the single-threaded one, even for the same program (as far as I understand it).

GHCi

Glasgow Haskell's repl uses the SMP runtime in 6.4.2 and newer versions (it has been an option for compiled programs for longer). GHC schedules lightweight user-space threads over a user-specified number of system threads.

Tcl has threads for quite

Tcl has threads for quite long now.

We used them quite succesfully.

Threaded 'language' vs interpreter

Tcl's threading support is excellent, and takes a smart approach. Instead of trying to create reentrant interpreter, it simply creates an interpreter per thread and lets you pass messages between them. So, technically, the interpreter itself is not "multi-threaded", but the approach is, IMO, superior - it's closer to what Erlang does.

JavaScript (!)

JavaScript is famously single-threaded. But the SpiderMonkey JavaScript engine actually does support native threading. Here's how it works: SpiderMonkey Internals: Thread Safety.

Reasons why Python's GIL is not likely to go away soon: Python wiki: GlobalInterpreterLock.

JRuby

JRuby is an interpreter/compiler for the Ruby language which directly exposes native threads.

In Erlang's case, the modern Erlang runtime schedules an arbitrary number of Erlang processes across a fixed number of hardware threads.