Most Ruby developers will never use C unless they really care about extracting every last drip of performance from something. In most production deployments I've seen, the only gem that is compiled from C is the mysql one, for example.
Except having lots of legacy Ruby libraries written in C ignores the real problem and prevents the Ruby VM from evolving.
For this reason alone Ruby will never have the capabilities of the JVM ... which has it all ... kernel threads (no GIL), async IO and userspace threads (through libraries like Kilim) ... making all kinds of parallelism / concurrency paradigms feasible (in some tests Kilim scales better than Erlang).
For most web apps this doesn't matter because the heavy processing is done by the DB, but have you ever seen a usable DB written in Ruby?
Here's a freakishly scalable one written in Java with no C libs dependencies ... http://neo4j.org/
I wish people would start supporting projects like Rubinius more ... who's main bottleneck is the limited support it provides for C extensions, because for speed improvements it pays better long-term to invest in the VM rather then improving bottlenecks by dropping to C (which IMHO actively hurts the platform).
Dropping to C should only be done for code reuse.
Ruby 1.9 has 90% of the features you mention above and RBX will soon remove the GIL on top of it. Async IO is arguably further along in Ruby then in Java.
Ruby will never be as fast as Java, but micro optimizations like the OP will not hold back the inevitable progress of ruby vms.
You compare a many thousand man years VM (HotSpot JVM)
to one that has been largely written by one person in
isolation ( Ruby 1.8 series ).
There are techniques first researched in the Smalltalk/Self implementations that have been known for at least 20 years (roughly the same time Ruby was born) that could've been used in Ruby 1.9.
Ruby 1.9 has 90% of the features you mention above and
RBX will soon remove the GIL on top of it.
It doesn't work that way.
One reason the GIL is here to stay is because of the many libraries written in C that depend on it.
Another reason would be performance degradation on single threaded programs ... removing the GIL on the whole needs major architectural changes ... just putting fine-grained locks on all mutable data structures won't cut it.
And yet another would be the garbage collector which also needs to be optimized for true multi-threading, otherwise it becomes a bottleneck. So add this on your list ... Ruby also needs a top-notch generational garbage-collector.
Async IO is arguably further along in Ruby then in Java
The solution seems obvious. Wrap them in a mutex by default and introducing an optional API call to remove the lock.
This way the important libraries will be fixed up gradually by the community and after a bit of time you won't have any C ext's left that will make use of the mutex and therefore the GIL will be gone.
That's the approach that rubinius is set to take.