Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Werner Schuster on Apr 07, 2008 08:10 PM
Nine months after JRuby 1.0 was released, and after 3 Release Candidates, the final JRuby 1.1 release is now available. InfoQ caught up with JRuby's Charles Nutter and Ola Bini to get details behind the changes in JRuby 1.1 and the future direction of the project.The biggest improvements are:He continues with his view on performance in JRuby 1.1:
We've also made hundreds upon hundreds of fixes for compatibility with Ruby 1.8.6. JRuby is by far the most compatible third-party implementation of Ruby available, and will be for a long time.
- A full compiler, turning Ruby code into Java bytecode
- The IO subsystem has been rewritten to better match Ruby's behavior
- Our new Regexp engine supports Ruby's strings with greatly improved performance
- Overall performance is many times better than any of the 1.0 releases
General Ruby code should almost all run a lot faster, especially if it uses regular expressions heavily. In general, we consider it a bug if a piece of Ruby code doesn't run faster in JRuby than in Ruby 1.8.6, so we're looking for bug reports to roust out any remaining bottlenecks.
Basically, the regular expression engine is a complete port of Oniguruma, the Regex engine that Ruby 1.9 will use. Our port was done by Marcin Mielżyński, and seems to have better performance and also fixes several bugs that are still in the Oniguruma original.Charles adds some more details:
The new implementation makes it possible for us to get better performance than any other Java based regex engine, while having extremely good compatibility with both Ruby 1.8 and Ruby 1.9. Most of the Re gexp and String methods have been totally redone to use the new engine effectively.
Because Ruby's strings are just byte collections, JRuby implements then using Java byte arrays. And because of this, none of the Java regular expression engines performed well for us; every regexp operation required converting byte[] to char[] and back. But Marcin Mielzynski, one of the JRuby committers, took on the effort of porting Oniguruma, a byte[]-based encoding-agnostic regular expression engine used heavily in Ruby 1.9. Because of his "Joni" library, we now have better regexp support than ever before, and basically all regexp performance issues have been resolved. It's a tremendous piece of work, and a great contribution.
Right now [1.9] doesn't affect us that much, since it's still a development release. I see two ways it helps us: first, the 1.9 features are more stabilized, which means it will be easier for us to add them correctly to JRuby. And secondly, since we are starting to see the real performance gains of 1.9 we also have a good goal to compare against, now that we have surpassed 1.8 in basically every benchmark.
We have already started adding 1.9 stuff to JRuby, and we will continue doing that continuously. Of course, correctness and fixing takes precedence right now. but for example the Oniguruma port makes it easy for us to add the encoding support to strings and so on.
We haven't talked that much about 2.0. Personally, I see 2.0 as the release that will be totally 1.9 AND 1.8 compatible. For 1.2 we will work on Java integration and external API's. Our Java Integration features work really well right now, but there are a few holes in the implementation, and also some inefficiencies, so we're planning on doing a total overhaul of that subsystem. This is of course a major thing to do, but the gains will be quite nice too.
You will see performance improvements in basically every area, but the most improvements will be in areas where we can statically figure out that stack based local variables are safe, that eval isn't used, that nothing funky is going on. In those methods we can generally get large improvements from the compiler and if they are hotspots in your program this will improve general runtime substantially.Charles offers his plans for the future:
After JRuby 1.1 the two big areas we want to look at are 1.9 support and better Java integration. That work may end up being JRuby 1.2 or it may be large enough that we go right to JRuby 2.0. And of course we'll continue improving performance to stay ahead of the pack...but right now we're pretty happy with it.
We're considering work on Ruby 1.9 features after JRuby 1.1 has been out for a while. However we're also hoping to see 1.9's feature set stabilize before we spend a lot of time in that area. We really don't want to chase 1.9 feature changes over the next year, especially since it seems that 1.9 is still evolving rapidly.
I think we need to expose the amazing dynlang potential of the JVM at any cost. If that means creating a new, possibly incompatible "fork" of OpenJDK, so be it. There's no reason such work can't be integrated back into Java proper, and there's a truly incredible VM there waiting to be tapped. I think this is going to be a very big year for OpenJDK, now that people realize what they have access to. And you can be there will be JRuby work taking advantage of any OpenJDK experiments people come up with.See more plans and projects to improve dynamic language support on the JVM or directly take a peek at the Da Vinci Machine website for details on the research.
Download the Free Adobe® Flex® Builder 3 Trial
Adobe® Rich Internet Application Project Portal
How Java Developers Can Write Great SQL
5 Ways to Ensure Application Performance
Performance Management and Diagnostics in Distributed Java and .NET Applications
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
No comments
Watch Thread Reply