You are viewing a read-only archive of the Blogs.Harvard network. Learn more.
Skip to content

RubyKaigi 2008 Day 1 Part 3 Notes

Evan Phoenix on Rubinius

Evan started off with a quick intro on Rubinius and proceeded to talk about some of the big pieces of Rubinius from a 10,000 feet high view.

  • The kernel of the system
  • The C Compatibility Layer
  • It’s a big project and Evan wants to have a conversation with anyone who wants to have one on it

For the VM nerds here are some feature highlights…

  • Accurate generational Garbage Collector
  • Bytecode based VM
  • Capable of bootstrapping itself

Evan suggested we should think of Rubinius sort of like an OS.

Then he started diving right into a tour of some of the cool internals of Rubinius and explaining some of the internal objects that really are the heart of Rubinius (above the VM layer)

BTW what is the <<? Evan coins it the left chevron.

  • MethodContext – Lets one see information regarding a method and the context surrounding it
  • CompiledMethod – Peek at the bytecodes of a method!
  • BlockContext – Tell me all the information about a block. Can capture a compiled block and inspect byte codes
  • SendSite – One per place where a call is performed. By caching information on this, can speed up method dispatch
  • With MethodContext and CompiledMethod it’s possible to implement eval in Ruby and follow the principle of Code as Data. Taking advantage of Ryan Davis’s ParseTree (included in Rubinius) one can take something like

    "1 + 1".to_sexp

    Which will take 1 + 1 and change it into an s-expression, convert it into an AST, and a User Visitor Pattern implementation can walk through this and spit out bytecode. (I might have recollected this wrong.. if so, sorry.. Not a VM implementor)

    Some other big features that Evan mentioned were

    • Extensions
      • Getting close to running Ruby C-extensions
      • However they are still 2nd-class citizens (they will take a performance hit but working is better than fast and broken)
      • MRI in this case is still faster
    • Multi-VM implementation
      • stdin and stdout are implemented as pipes
      • Functional but still highly experimental (can try calculating Pi across a multi-core machine)
      • args = [“-e”, “puts”, “hello”]
        vm = Rubinius::Vm.spawn args
        puts vm.stdout.gets
    • Channels
      • One of the main internal communication channels used in Rubinius
      • I/O events use channels for example

    Then Evan goes on to showing some cool demo of implementing Binding.of_caller in front of the audience. He also showed one neat thing about rbx. If you run a command it will load irb automatically assuming you want a REPL (cool!)

    Q & A

    • Q: What are your final goals with Rubinius?
    • A: Have an image like SmallTalk? The VM only knows about byte codes not Ruby. Could even write an implementation of SmallTalk on the Rubinius VM however Evan said he has no plans to
    • Q: Anything on shared benchmark testing?
    • A: (Matz) There has been movements to start collecting code as of last week. Trying to make sure that it is more ‘real world’ code benchmarks. There should be an Infoq article on this.
      (Evan) Started on this. Check out GitHub for more info
    • Q: How’s the performance?
    • A: No really hard numbers on Rubinius’ performance. Some things have gotten faster over time such as the generational part. Awhile ago Evan wrote a bunch of small benchmarks to test things out but seems to have misplaced them somewhere
    Be Sociable, Share!