[MacRuby-devel] experimental branch: status update

[Matt Aimonetti]

Awesome job Laurent, as usual!

- Matt

On Mon, Jun 29, 2009 at 1:19 PM, Laurent Sansonetti
<lsansonetti at apple.com>wrote:

> 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
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20090629/35918b18/attachment-0001.html>