gdp's Comments

Union Station : Ruby I/O Performance - what, where and when

Wed, 26 Jan 2011 13:57:52 +0000

For your sudoku solver, I ran some numbers of my own with client and server JVM. I was running on OS X, but the numbers should translate to most platforms (including Windows). With the client VM, after warmup, JRuby's run time is around 4.4s. With the server vM, JRuby's run time improves to around 3.3s. This is a good improvement, but it's not as good as it should be. There's a few specific aspects of this benchmark that JRuby currently does not optimize well. The nested "upto" blocks cause too much overhead in current JRuby. Blocks are ok, but nested blocks currently cause some issues for the way we optimize Ruby code. I'll see if I can improve the sudoku benchmark. I'm also not sure why you even included JRuby in this post, when you only post numbers for JRuby on a sudoku microbenchmark and a startup time benchmark. Perhaps it would be more interesting to see a real application running on JRuby, or perhaps actually show JRuby's IO performance numbers too.

Union Station : Ruby I/O Performance - what, where and when

Wed, 26 Jan 2011 13:24:39 +0000

You ran JRuby with Hotspot in client mode. JRuby with the "server" mode is generally much faster, anywhere from 2-3x for CPU-intensive code. Your JRuby numbers are invalid :)

Union Station : JRuby 1.6.0 RC1 Released

Thu, 13 Jan 2011 20:22:19 +0000

Yes, unfortunately because Ruby 1.9 includes a broken "gem_prelude.rb" it loads on every startup, we needed to do something similar. To avoid the brokenness, we simply require 'rubygems', which while faster than in previous versions does incur a startup hit. There are also additional native core classes like Complex and Rational that need to be set up. We hope to make more startup-time improvements before final.

Union Station : JRuby 1.6.0 RC1 Released

Thu, 13 Jan 2011 20:20:27 +0000

Fibers are supported, but be careful: they must spin up a native thread per-fiber, so they're much heavier than under Ruby 1.9. Continuations are supported only as well as in previous versions of JRuby (that is, not well...the JVM does not support continuations).

Union Station : Rubinius wants to help YOU make Ruby better

Tue, 31 Aug 2010 00:38:19 +0000

Rubinius has done a great job blazing a trail with regards to native libraries and native extensions, and we're very happy we've been able to support the same FFI and C extension APIs in JRuby. That makes Brian's comments about "Neighborly C extensions" even more important, since JRuby suffers from the same limitations that Rubinius does when it comes to writing C extensions to MRI's API. RHASH and RSTRING->ptr are just the tip of the iceberg. Do not expect to have access to class method tables (we both implement them differently). Do not try to find the various MRI runtime structures (like the AST, frames, or scope objects)...we have completely different execution models. Do not expect C extension code to run concurrently (on JRuby now or on Rubinius when it supports concurrent execution). Because of the global nature of many C extensions' state, we both must ensure only one thread hits C code at a time. And above all know that because JRuby and Rubinius must isolate C code from the locations of Ruby objects in memory, C extensions with very fine-grained APIs (e.g. every method on every class does a call-out to C) are going to perform *much* worse on JRuby and Rubinius due to the extra copying and indirection required. Design your APIs well and with these limitations very much in mind. (I would also be lying if I said JRuby's C extension support were the recommended path forward. It will work well as a stopgap measure, but the ultimate solution will usually be to port to Java or find an equivalent Java library to use that doesn't suffer from performance and concurrency penalties.) That said, we still want C extensions to work as well as possible just like the Rubinius guys, and we'll stand with them to educate people (and to work with CRuby's core team!) on how to write fast, reliable extensions. (And of course the remaining points Brian makes about good OO design apply to any environment...I wholeheartedly agree!)

Union Station : Introducing JRubyConf 2010

Thu, 26 Aug 2010 21:30:14 +0000

I thought I'd also mention that three at least JRuby core developers (Tom Enebo, Nick Sieger, and I) will be at JRubyConf 2010 to answer your questions and help you with any JRuby-related issues you might have. This is your chance to meet up with us and other JRubyists, and we're looking forward to seeing you there! :)

LoGeek's software blog - learning content for developers : On JRuby, Resque and Windows

Wed, 11 Aug 2010 21:58:16 +0000

Nice post, and it seems like a good use of JRuby to me. Pretty cool way to mask the fact that you have this "big ugly thing" over on Windows that stubbornly refuses to run anywhere else. Have you considered using JRuby for the other end of your app too? It might be possible to do everything JRuby-based, if that would make sense for your application.

Union Station : Monitoring Memory with JRuby, Part 1: jhat and VisualVM

Sat, 7 Aug 2010 15:08:51 +0000

So far, I have not. The timezone data appears to be normal but perhaps a bit wasteful, since most applications will never need all that timezone information. The right fix would probably be to lazy load such data, but I'm not yet familiar enough with the library to do that. Exercise for the reader? Part two will go into another tool for browsing JRuby heap dumps: The Eclipse Memory Analysis Tool.

Union Station : Monitoring Memory with JRuby, Part 1: jhat and VisualVM

Sat, 7 Aug 2010 15:07:35 +0000

It's there, at the very bottom in tiny gray print: "This article was originally published on Charles Nutter’s blog Headius." I agree it could be made more prominent :)

Union Station : Monitoring Memory with JRuby, Part 1: jhat and VisualVM

Sat, 7 Aug 2010 15:06:49 +0000

OQL can query against instance variables, but it's a bit more roundabout. You need to look first at the object's metaclass, which holds an array of instance variable names. The index of the name is the index into an instance variable table on the object itself. For that sort of thing the current tools are a bit "raw" since the Ruby object structure doesn't map directly to Java, but I hope to fix that (by having at least the "known" instance variables generated into regular Java fields when the "real" Java class is created).

Union Station : Monitoring the JVM Heap with JRuby

Fri, 14 May 2010 08:38:10 +0000

igrigorik: Yes, it's absolutely possible, and actually pretty easy. Hopefully we can get Tom Enebo to do a post on how to do it, but otherwise email us and we'll set you up.

Union Station : Monitoring the JVM Heap with JRuby

Thu, 29 Apr 2010 19:45:09 +0000

Brian: Yeah, the great thing about Java Management eXtensions (JMX, which is where the "MX" in "MXBeans" comes from) is that services like New Relic can monitor your app through a standard interface. JRuby publishes some MXBeans for internal information like how much time has been spent parsing, and Tom Enebo's "jmx" gem makes it trivial to define your own MXBeans entirely in Ruby. Hopefully we'll have some posts on that stuff soon.

Union Station : Rake and Ant Together: A Pick It n' Stick It Approach

Fri, 19 Feb 2010 19:57:59 +0000

Really nice post and features. It's everything I've wanted from ant+rake integration. And for those not in the know: it's also an incredibly small amount of code in JRuby, considering all it does: http://github.com/jruby/jruby/tree/master/lib/rub... and http://github.com/jruby/jruby/tree/master/src/org...

Union Station : Getting Started With JRuby

Wed, 4 Nov 2009 07:32:55 +0000

Curious: Yes, what you say is true; this is more an "intro to JRuby for Ruby folks". But that is largely the point...up until this point, Ruby and Rails are just Ruby and Rails, regardless of whether you are on JRuby or not. We've made it a key point of JRuby that Ruby should "just work", so any tutorial you'd follow to get a Ruby or Rails application working should work the same on JRuby as it does on any other Ruby. You are correct, though. We on the JRuby team need help selling "Ruby" to the non-Ruby masses. We're so close to Ruby that we forget (or at least don't address the fact) that Ruby itself requires a bit of selling at times. Most of our presentations and posts are focused on people who have already decided Ruby is the way to go. Hopefully as JRuby continues to gain momentum, we'll see more folks from the Ruby world selling to non-Ruby developers, and since many of those developers are using JVM-based libraries and languages, JRuby will be a natural progression.

Union Station : JRuby's Future at Engine Yard

Tue, 4 Aug 2009 07:57:24 +0000

That may be the case, but the purchaser doesn't simply throw a dart at a board. They measure reliability, supportability, TCO, ROI, TTM. Rails covers a number of those, and a commercially-backed JRuby can cover most of the others. And I think we've shown that JRuby is a strong, viable technology made stronger by the backing of a world-class Ruby and Rails company. However, I'd love to talk with you offline about your theories on adoption. I'm sure we could learn from you and you may be able to learn from us. Our goal is to make JRuby the best JVM language and runtime we can possibly make it, and we'll leave no stone unturned along that path. Feel free to email me directly.

Union Station : JRuby's Future at Engine Yard

Tue, 4 Aug 2009 07:51:03 +0000

I should also mention that we have the deepest respect for Sun and loved working with them. They helped teach us the value of the developer, and helped us realize that technology decisions are made (and should be made) from the bottom up. We look forward to continuing to make JRuby the "developer's best friend", just like Ruby is a language "optimized for programmers happiness."

Union Station : JRuby's Future at Engine Yard

Tue, 4 Aug 2009 07:39:02 +0000

I personally believe that enterprise acceptance starts with developers, and developers no longer trust the big, lumbering corporations like they used to. The JVM is the Platform of the People, and Ruby is the people-oriented language. Together they make a perfect combination, and what better company to shepherd the next round of JRuby evolution than Engine Yard?

Union Station : JRuby's Future at Engine Yard

Tue, 4 Aug 2009 07:36:44 +0000

Domo Arigato, Luigi! First off, you should check out my blog post from this weekend: http://blog.headius.com/2009/08/return-of-ruboto.... Ruboto (JRuby for Android) lives! And we're not the only ones that think JRuby on Android is an awesome idea...the Android Scripting Environment now supports JRuby too: http://amazing-development.com/archives/2009/08/0... We (The JRuby Team) plan to also make JRuby usable as an *application* language for Android, with all the capabilities (and hopefully equivalent performance) as Java-based apps. We also received many comments from people trying out JRuby on Android this weekend, and several of them are interested in working with the JRuby team to build it into a first-class runtime for the Android platform. So rest assured, JRuby on Android is moving forward very quickly now.