Inside the full speed Rubinius debugger
The default Ruby debugger is implemented in Ruby, with a Ruby block simply set with
set_trace_func. Faster versions of this approach were implemented in C (ruby-debug, Cylon debugger) and Java (jruby-debug). However, no matter how fast the callback is executed, the problem of this solution remains: as soon as the debugger is started, every line of Ruby code incurs an overhead.
An ideal solution for this has no overhead and simply suspends the thread when a breakpoint is hit. I.e. a breakpoint has no cost (in CPU cycles) until it's hit. This is the approach that Rubinius' full speed debugger uses - with "full speed" meaning that a program runs at it's normal speed even if it's being debugged.
Rubinius' full speed debugger is made possible by these characteristics:
- Rubinius compiles all Ruby code into instructions (op_codes) which the shotgun VM runs - currently with a op_code interpreter
- The full speed debugger functionality introduced a new instruction yield_debugger which - when executed - notifies the debugger thread on a defined debugging channel (Channels are a kind of pipe - i.e. data sent into it can be received on the other end).
- It's possible to access the bytecode for a Method - actually it's trivial to do so. Here an example with
m = "".method(:to_s) cm = b.compiled_method
# this yields an array of InstructionSet::Opcode objects cm.bytecodes.decode
- Various utility methods help map instruction offsets to line numbers, such as
- Take the Method object and get it's
- Figure out the position of the first instruction of the line of the breakpoint.
- Exchange the instruction at this position with
yield_debugger. The original instruction is kept around in a management data structure.
- After the breakpoint is hit and the user continues execution, the original instruction is executed and then normal execution of the code resumes.
sendermethod doing just that.
Using the debugger is simple. Once you have Rubinius (see how to check out and compile Rubinius), start
shotgun/rubiniusThen execute this:
Rubinius::VM::debugger(Note: just typing
debuggeralso works at the moment). This will put you in the debugger's text interface - available commands can be seen with the "?" command, and include managing breakpoints and features like looking at the op_codes and the Ruby source of methods among others.
The full speed debugger gives Rubinius a big edge versus Ruby implementations that need to rely on tracing based debuggers (no matter how fast these implementations are). It's also important to note: the complete debugger functionality was written in Ruby - with the exception of the handful of lines of C code for the
Have you tried Rubinius yet? Do you have ideas what you could do with Rubinius' transparency and accessible internals, i.e. accessing and modifying bytecode at runtime, inspecting the call stack etc.?
Also: check out InfoQ's previous coverage of Rubinius.
Evolving Culture and Values. Understanding the Tradeoffs. Growth through Failure. The Importance of Leadership and Open Communication.
Pedram Keyani Mar 11, 2014
Summly: An Award Winning Mobile App's Journey to the Cloud with Five-9s Availability on a Shoestring Budget
Eugene Ciurana Mar 11, 2014
Christophe Achouiantz Mar 11, 2014