BT

RubyKaigi 2008: Standardization, 1.9 Roadmap

by Kaz Tajima and Mirko Stocker on Jul 03, 2008 |

This is the second part of InfoQ's RubyKaigi 2008 coverage, for the first part, see the discussion with Matz.

Ruby Standardization

Yukihiro "Matz" Matsumoto expressed his intention to standardize Ruby. The aims of the standardization are to improve the compatibility between different Ruby implementations like JRuby and IronRuby and to ease Ruby's way into the Japanese government, which in 2007 announced guidelines to use open standards rather than specific products. Matz plans to hand in the standard to the ISO (International Organization for Standardization), however, a concrete date has not yet been determined—only that it will "at least take a couple of years for standardization".

Ruby 1.9x Roadmap

On the second day of the conference, Koichi Sasada—the developer of YARV—unveiled the roadmap for Ruby 1.9x and announced his plans to release the stable version 1.9.1 by Christmas 2008. The currently available Ruby 1.9.0 was always intended to be a development release, whereas 1.9.1 is planned to be the first stable release from the 1.9 series, and therefore to be used in production. On the same day, the updated versions 1.9.0-2, 1.8.7-p22, 1.8.6-p230, and 1.8.5-p231 were released too.

The roadmap for 1.9 is shown below:

  • Jul 25 1.9.0-3
  • Aug 25 1.9.0-4
  • Sep 25 1.9.0-5 (feature freeze)
  • Oct 25 1.9.0-6 (1.9.1 RC1)
  • Nov 25 1.9.0-7 (1.9.1 RC2)
  • Dec 20 1.9.1

The Next Ruby

Koichi Sasada also talked about possible features that might get implemented in future versions of Ruby.

  • MVM Multiple virtual machine (MVM) support for Ruby, for example to establish Ruby on cell phones.
  • Atomic Ruby The build of Ruby can be performed containing only necessary modules. Atomic Ruby targets embedded devices.
  • Byte Code Serialization As a technology to enable Atomic Ruby, byte code serialization might be helpful; because there's no need to analyze the source code, the parser isn't needed anymore and can be excluded from the build if the complete serialized byte code is included. This could prove useful for microcomputer controllers in home appliances or to distribute code to other nodes in a cluster.
  • Byte Code to C translator By generating source code from the bytecode, optimizations of existing C compilers can be applied and enable platforms that don't have a Ruby implementation.
  • Optimization for HPC Floating point numbers can be treated as an immediate value on 64-bit machines. Compared to the method of securing the floating number on the heap, this halves the fetch count and makes it faster as well as decreasing garbage collecting activities. Studies have shown that this almost doubles the performance of floating point arithmetic.
  • Review of Memory Allocator and GC Because the GC and memory allocation costs increased with the introduction of YARV, it seems valid to consider a realtime GC or a compacting GC.
  • Effective Deoptimization In response to class reloading and method redefinitions, JIT-compiled code can be restored to be then modified.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT