RubyKaigi 2008: Standardization, 1.9 Roadmap

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

Sections

Development

Topics

Runtimes ,

Ruby

Tags

Standardization ,

RubySpec ,

MVM ,

Ruby1.9 ,

Virtual Machines ,

GarbageCollection

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.

• Older >