Re: Experimental PATCH to improve thread performance

Brent Roman wrote:
> 
> Charles Oliver Nutter-2 wrote:
>>
>> I'd love to know what broke in JRuby. I tried both benchmarks and 
>> they're very snappy on my machine. We're making a big push to get JRuby 
>> threading solid, so please let us know what you've seen.
>>
>>
> 
> I'd like to work with you on this after the holidays.
> In the meantime, I've attached a java backtrace
> of the failure in our dreaded "killer app"
> Let me know if you can glean anything from it that will
> help me create a simple test case for you.
> 
> http://www.nabble.com/file/p14467248/jruby-1.1b1.backtrace
> jruby-1.1b1.backtrace 
> 
> By the way,
> The benchmark numbers I see here are very consistent with your claim
> that JRuby is faster than Ruby 1.8.6.  In this case, it's a lot faster:
> 
>                Unpatched 1.8.6    Patched 1.8.6   JRuby 1.1b1      Ruby 1.9
> Bench #1  22sec / 16 MB       4sec  / 7 MB     3.5sec / 21 MB    0.06sec
> Bench #2  35sec / 10 MB      15sec  / 7 MB    2.8sec / 17 MB    0.36sec
> 
> I realize that these numbers penalize JRuby for its JVM start up delay,
> but, even so, it's clear that when Ruby 1.9 is finally ready, 
> it will be the horse to beat ;-)
> 
> Note that I had to patch my version of 1.9 to implement Thread.critical=
> to run benchmark #2.  This is quite straightforward as long as the
> global interpreter lock continues to exist.  I'm surprised that 
> JRuby accepts Thread.critical=.  How did JRuby implement this
> atop a JVM?

In JRuby, all threads executing Ruby code checkpoint at the same places 
Ruby 1.8.6 checks if a context switch is indicated. In Ruby 1.8.6 that 
context switch flag is set every 10ms (10ms timeslicing), but in JRuby, 
we only look for cross-thread events at these checkpoints since threads 
are running concurrently.

See my description of threading in Ruby here:

http://spec.ruby-doc.org/wiki/Ruby_Threading

and JRuby here:

http://spec.ruby-doc.org/wiki/JRuby_Threading

Both haven't been updated in a while, but should still be correct. I'd 
love to have a Ruby 1.9 article alongside them, and I hope you and 
others will make updates to either article as you see fit.

Checkpointing does introduce some overhead, but we've pared it down a 
lot to avoid locking as much as possible. I'd love to see a day where we 
could turn off all the dangerous cross-thread operations, effectively 
eliminating checkpointing entirely, but I don't think it's likely to happen.

Provably unsafe thread operations Ruby supports and should not:

stop
exit/exit!/kill/kill!/terminate/terminate!
raise
global abort_on_exception

Operations which are largely incompatible with concurrent threading 
(which Ruby can't support if it wants to support concurrent threading well):

critical=

I'll enumerate the reasons why these are unsafe if anyone wants to know. 
I think Java's threading is a good model here; it provides the thread 
operations that can be safely supported and does not provide the others.

Here's an article that explains some of the reasons:

http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html

- Charlie