JRuby

Yes, you read that right! I'm announcing my intent to circumnavigate the globe in only NINE DAYS spreading JRuby and joy at every stop. The Earth shall be wrapped in JRuby goodness!To celebrate this monumental occasion, I'm inviting all developers ... [More] with an interest in Ruby or Java to join the JRuby mailing lists and volunteer your services. Eternal gratitude and temporary fame could be yours, for the small price of bug reports, bug fixes, or high-performance rewrites of core JRuby libraries (it's so easy!). Operators are standing by to receive your emails and direct you to the promised land!Now, on to the tour!First Stop: Amsterdam, NetherlandsThe first leg of my journey takes me from my home in Minneapolis, Minnesota to beautiful Amsterdam. There I will enjoy an delicious airport breakfast followed by a five-hour tour of the terminal. I will be available for autograph signing from 7:00 to 11:30 by appointment only. The first annual JRuby New-Age Concert of Magic will follow from 11:30 to 11:35. Tickets are first-come, first-served; cash only, please! I will depart from Amsterdam at 11:55 via a chartered jet I'm generously sharing with three-hundred other passengers and a small KLM Dutch Airways flight crew, en route to exotic Hyderabad, India!Second Stop: Hyderabad, IndiaThe next part of the JRuby "World Domination Tour 2007" takes me to Sun's Tech Days event in Hyderabad. In addition to my JRuby session, Tech Days will host such scintillating topics as "iPod Giveaway" and "Java Jacket Giveaway". But on Wednesday the 21st at 3:35PM you too can learn why JRuby is the programming alchemist's "Developer's Stone", transmuting static lead into dynamic gold. The topics covered will be exactly like those in recent JRuby talks, except cooler, faster, and after 26 hours of non-stop travel and five hours of sleep. Prepare for a punchy, laugh-riotous affair! Will I be able to maintain 90WPM during my interactive demonstrations? Will I remember that "alias" takes two arguments *without* a comma and with the original method first? Join me for what's sure to be 50 minutes you'll remember the rest of your life!Third Stop: Bangalore, IndiaFrom Hyderabad, I take a short one-hour flight to Bangalore, home to Sun Microsystems India and the third leg of the JRuby Globe-trotting Festival of Light! On Monday, February 23rd, I will present JRuby to my tropical counterparts on the opposite side of the earth, featuring the exact same topics from Tech Days...in RANDOM ORDER. You never know what I'm going to do next.I actually have all that Sunday free and Tuesday up until about 8:00 free to do some exploring. Event suggestions are welcome, and I challenge any of you to find food too spicy for me to eat! (impossible, I say!)Fourth Stop: Bangkok, ThailandThe next step takes me from Bangalore to beautiful Thailand, jewel of Southeast Asia and home to one of my favorite cuisines. I will be available from 4:00AM to 5:30AM for a special, once-of-a-lifetime event I'm calling "JRuby Dawn at Bangkok Airport". And the great question on everyone's lips will be foremost on my mind:Will the airport's Thai restaurants open before I board my next flight at 6:00? Stay Tuned!Fifth Stop: Tokyo, JapanContinuing the Asian leg of the tour, I'll spend 80 fun-filled minutes exploring the international terminal in Narita, only an hour's train ride from the Emperor's Palace! Naturally I'll be available for handshakes and baby-kissing, and hopefully the always-humorous photograph of "buying beer from a vending machine". This trip will serve as a preview for the main Tokyo event: Ruby Kaigi 2007 in June, where I'll finally present JRuby to the Land of the Rising Sun. Come 3:10PM it's time for "so long Japan", but I'll be back soon!Sixth Stop: Minneapolis, MinnesotaAnd just 9 days after I departed, I'll be home in Minneapolis again, ready for my next thrilling adventure: The Greater Wisconsin Software Symposium (a No Fluff Just Stuff event) in Milwaukee from March 2-4. Join me for my two fabulous sessions "Bringing Ruby and Rails to the JVM" and "Become Super-Powerful with JRuby", putting the greatest dynamic language ever in the palm of your JVM. [Less]

  I have been working on a branch for the last couple of weeks.  This branch does the following things:1. Invert the relationship of IterNode/BlockPassNode with CallNode/FCallNode/SuperNode2. Remove iter and block structures from ThreadContext and ... [More] pass current block around on the native Java frame (e.g. pass as parameter to all methods that need it)  We wanted to invert the relationship between nodes for some time now.  IterNodes (or BlockPassNodes) are really children of the calls.  Up until this branch (and in MRI) is was the other way around.   I believe this backwards relationship came into being in MRI (and I suppose someone would explain this if I bothered to ask) was that by reversing this relationship it was easier to bookend the iter and block structures maintenance functions within the evaluator.  These maintenance functions and the need to have iter and block structures is the other thing we didn't want.  By maintaining these structures we are in essence doing something that could be maintained by Java itself.  So really this is extra work to us.  By passing blocks around through function calls we basically manage our blocks by sticking them into the Java frame itself.  I have currently exhausted the brnach of errors and a simple Rails app works.  I ran several of the usual suspects to try and break things.   I think there will be some outstanding issues, but hopefully they will be small issues related to doing such  large patch (~17,000 lines).  Here are some simple performance numbers.  They are not large gains, but they do show some improvement and we are doing less work for non-fast methods.  If we did not have fast methods these numbers would have looked a lot better, but fast methods are here and a good idea.  Anyways:Test                  JRE          Trunk        Branch       Notesquicksort         Java5      44s             42.3s         -server (no STI)fib_recursive   Java5      6.3s            6.1s           -server (no STI)fib_recursive   Java5      5.8s            4.9s           -server (STI)fib_recursive   Java6      ---             4.2s           -server (STI)fib_iterative     Java5      13.6s         13.1s          -server (no STI)Notes: STI was broken when I ran some of these tests.  I should have tested more with Java 6, but I felt testing against 5 is more likely to reflect what more users are using.  I should have benched Ruby on these as well, but they are really only intended to give an idea of relative performance. [Less]

I wanted to get a feel for Ola's latest commit to see what sort of improvement it will yield.   This code dynamically generates bytecode to perform direct invocation to get away from using Java's reflection library's.I used the following script ... [More] (quick mod from another script since the other script hit a method which used a different dispatch mechanism):require 'benchmark'puts "Test: 100k loops calling arity 100 times"100.times {puts Benchmark.measure {  t = Time.now; a = 5; a = a.method(" ")  i = 0;  while i < 100000    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity; a.arity;    i = 1;  end  puts Time.now - t;}}I then ran this script with reflection enabled and disabled (generated direct invocation):Test: 100k loops accessing a fixnum method and calling arity 100 times            -client (java5)                   |              -server (java 5)  reflection  compileddi  mreflected|reflection  compileddi  mreflected---------------------------------- -----------------------------------  7.656000 7.546000 24.547000 | 5.484000 5.546000  5.750000  7.375000 7.297000 25.094000 | 6.328000 6.359000  5.938000  7.312000 7.281000 25.031000 | 6.016000 6.047000  5.750000  7.266000 7.297000 24.657000 | 6.125000 6.047000  5.812000Each row represents a completed loop as time goes on you can see the JVM hotspot optimizations that start to take affect.  In some cases things end up deoptimizing.  Lets compare some more specific numbers.So looking at Java with -client was the first thing I did.  If you compare using reflection against the compiled direct invocation code you can see that the direct invocation starts out faster and after hotspot kicks in long enough things kind become a tie.  What is significant to me is that the compiled di code starts out faster and does not need hotspot as much.  A clear winner for short running code which may not get the benefits of running long enough to be hotspotted.For fun, I wanted to see how this code would work with another dispatching mechanism which I call mreflected.  The 'm' in that stands for meta and it is just another way of using Java reflection to invoke methods.  I quickly ported the Method code to use mreflected and as you can see from the numbers under client something is horribly wrong.  It runs over 3x slower than the other two mechanisms.  Weird.  We are doing something that hotspot cannot figure out....Or can it.Next thing is running these dispatch mechanisms with -server.  You can now see that mreflected clearly wins over the other two.  You can also see that hotspot deoptimizes something in the other two.So what is the summary of this?  hotspot rocks.  The best code is code which behaves best in client AND server and does not rely on hotspot for speed increases.  Testing this stuff is very difficult to do....Especially if you consider I only tested Java 5.  If I tested Java 1.4 or Java 6 the results will vary.   Writing good code is tough and verifying it is good is almost as tough.... [Less]