[MacRuby-devel] experimental branch: status update

[Laurent Sansonetti]

Last week's status on the experimental branch work!

- It's now possible to build MacRuby with clang (assuming you  
installed it) by issuing the following command:
$ rake use_clang=true miniruby
This will compile all C and Objective-C files with clang and C++ files  
with llvm-g++. Apparently the build's product works as expected.  
However, since clang is a moving target and since it does not support C 
++ yet, this option is not enabled by default even if you have clang  
in your system.
- Threads!

A first multi-threaded design for MacRuby was implemented. The idea  
behind this design is to map a Thread object to a native POSIX thread  
and make sure its related block will most always run in a concurrent  
fashion.

In order to achieve this, we created a new class called Core, which is  
a singleton object containing all the data structures that should be  
shared across all threads. The Core object contains a lock that is  
used every time a shared data structure is accessed. Shared data  
structures are for example: LLVM caches, various stubs caches,  
BridgeSupport caches, etc.

Everything else was moved to a VM class, which is completely lock- 
free. A VM object is created at demand and only once for every thread  
that wants to access the runtime. The VM object contains data  
structures for the very specific thread execution, like for instance  
current blocks, bindings, exceptions, etc. The VM sometimes calls the  
Core (when defining a method for example) which acquires the Core  
lock, but most of the time it just runs concurrently. All MacRuby  
threads are scheduled by the OS kernel and registered into the  
Objective-C garbage collector (which runs on its own threads) before  
doing anything.

This implementation is not quite finished yet and will be polished in  
the near future, but it's already very promising. It passes all the  
RubySpec core/thread expectations and according to a few benchmarks we  
can finally use multiple CPU cores. I was able to run some micro- 
benchmark code (like fib(40), method dispatch loops, etc.) on 8  
different Threads on a Mac Pro and MacRuby was using 800% of the  
system (all 8 cores) vs only one in the case of Ruby 1.9.

Obviously since threads are concurrent it means the developer must  
take this into account and use mutexes to secure access to a shared  
object (local variable, instance variable, etc.), which is not  
necessarily needed in Ruby 1.8 or 1.9 because threads don't run  
concurrently.

Also, Thread#kill is supported but is really discouraged because it's  
not deterministic.

I wrote for fun a simple web server on top of Foundation's run loop  
that dispatches new HTTP requests to a pool of threads, to test a  
little bit our implementation and see if it's stable. I stressed it  
with ab(1) (Apache benchmarking tool) and it's quite good, there are  
still 2-3 random bugs but I think I identified all of them. If you're  
interested, the simple web server was committed in sample-macruby/ 
Scripts/web_server.rb.

That's all folks! Threads was really the last piece of functionality  
missing in experimental vs trunk. Now it's time to converge and try to  
fix all the remaining bugs.

Laurent