VisualVM: JRuby and the Ruby to JVM Spectrum

As I have worked with JRuby, it has been interesting to observe the intersection of the Java and Ruby communities. Because JRuby potentially combines with best of the JVM with the best of Ruby, it is perhaps not surprising that JRuby leads to a greater intersection of the Java community and the Ruby community. For example, because I have been working primarily in Java in recent months, I probably would not have been aware of the major controversy in the Ruby community surrounding a single presentation given recently at the Golden Gate Ruby Conference (GoGaRuCo).

Many Rubyists like to focus on the Ruby advantages that JRuby brings to Java, but there is no denying that JRuby also brings advantages of the JVM to Ruby. One particular area of interest here is the impact of the JVM on JRuby performance. In How JRuby makes Ruby Fast, Charles Nutter demonstrates how JRuby's performance improves as more JVM features (server mode, JIT compiling, and so forth) are employed. Some strict Ruby compliance must be sacrificed for some of the performance improvements, but this flexibility to selectively choose between the best features of Ruby and the JVM is one of the endearing features of JRuby.

As described in the JRubyWiki topic Performance Tuning, JRuby performance can be tweaked with JVM arguments and properties. Although these properties and JVM arguments can be set on the command-line, there are times you may want to know which ones are being used or what the default settings are. This is where VisualVM makes things really easy.

VisualVM is included with recent versions of Sun's implementation Java SE 6. It in many ways serves as a replacement for JConsole and a host of command-line tools provided with Sun's SDK. In his post Can Your Ruby Do This?, Ola Bini points out how JRuby is able to take advantage of the built-in JMX support in Java SE 6 for automatic detection, monitoring, and management. Similarly, VisualVM can be used to monitor JRuby processes by virtue of them running in the JVM.

To demonstrate this, I'll use VisualVM to monitor the running JIRB (JRuby's Interactive Ruby) tool. With jirb started on my local machine (it could also be accessed remotely, but local is slightly easier), I see the running process when I start Visual VM (jvisualvm at the command line) as shown in the next screen snapshot.



In this case, the only other Java process running on my local machine is VisualVM itself. This also provides evidence that JIRB does indeed run as a Java process (using class org.jruby.Main). When I click on the JRuby process, I can see the JVM arguments used in conjunction with running jirb as shown next.



Because I had downloaded and installed the JConsole-like MBeans plug-in for VisualVM earlier, the JMX-exposed MBeans for JIRB are available. These are shown in the next screen snapshot in the MBeans tab (this tab is not available in VisualVM until it is explicitly downloaded and installed using Tools-->Plugins).



As the last image indicates, the JRuby process exposes a long list of configuration items for viewing. This allows VisualVM, JConsole, or any other JMX-enabled client to see how the JRuby runtime is configured in that particular case.

JRuby brings together the Java world and the Ruby world both in technical aspects and in people/community/political aspects.