Rubinius全速调试器技术内幕

作者 Werner Schuster译者 马家宽 发布于 2008年1月29日 下午11时11分

社区

Ruby

主题

性能和可伸缩性,

调试,

技术,

运行时

标签

Rubinius,

SmallTalk

Ruby的调试器支持早已有之——长久以来，Ruby发行时都附带着一个命令行调试器。不过，调试器的速度一直是个问题。通常，Ruby调试器使用诸如 Ruby的回调（callback）块或通过在Ruby代码执行前调用函数来实现。回调会检查线程是否挂起或该行代码是否存在断点。

Ruby的自带调试器使用Ruby实现，包含一个通过set_trace_func设置的Ruby块。这一方法的更快速版本则采用了C（ruby-debug，Cylon debugger）和Java(jruby-debug)作为实现语言。然而，无论回调执行的多快，这种解决方案的问题都始终存在：只要debugger一启动，所调试Ruby程序的每一行代码都会承受额外的开销。

对于这一问题的理想解决方案应该是不引入额外开销，然后在遇到断点时将线程挂起。也就是在被触发前，断点不会带来（CPU时钟周期方面的）任何代价。这正是Rubinius的全速调试器所采用的方案——这里的“全速”意指程序即便是在被调试时，也能保持正常的运行速度。

如下的特性使得Rubinius调试器的全速成为可能：

• 将所有的Ruby代码转换成shotgun虚拟机所执行的指令（op_codes）——目前通过op_code解释器执行
• 全速调试功能引入了一条名为yield_debugger 的新指令——当该指令执行时会通知位于一个已定义channel之上的调试器线程（channels是一种管道，也就是说从一端放入其中的数据可以在另一端接收到）
• 方法的字节码可以被访问——实际上这一做法通常比较细微。这里示例一个String类的to_s方法：

  m = "".method(:to_s) cm = b.compiled_method
  # this yields an array of InstructionSet::Opcode objects cm.bytecodes.decode  

• 多种工具方法为将指令偏移对应到行号提供帮助，例如CompiledMethod的first_ip_on_line方法等。

有了这个功能之后，可以非常简单地在某个方法的特定行中设置断点

• 获取这个方法的Method对象和对应的CompiledMethod对象
• 指出这个断点行的第一条指令的位置 
• 把该位置的指令变成yield_debugger。原先的指令会被保存在一个用于管理的数据结构中
• 在到达这个断点并且用户选择继续执行之后，原先的指令会被执行，而后会按正常的序列执行代码

这个功能已经存在一段时间了（参见InfoQ: Evan Phoenix访谈 - 深入Rubinius：线程、对象空间、调试）。不过因为Adam Gardinerd的工作，这个全速调试器现在可以被一般用户使用了。Adam Gardiner为Rubinius debugger增加了基于命令行的用户界面以 及一些必要的命令。不仅如此，他编写的功能允许用户进行逐行单步调试。要使用这个功能只需要把当前断点的下一行也设为断点即可。当然，这个功能还需要了解 当前行是不是方法中的最后一行。不过在Rubinius中通过获取调用当前断点方法的句柄，这个信息也是可以得到的。因为上下文对象，例如方法活动栈，拥 有一个sender方法实现了这个功能。

调试器的使用很简单。在您装好了Rubinius后（查看如何检出并编译Rubinius），通过如下方式启动irb：

shotgun/rubinius 

然后执行：

Rubinius::VM::debugger 

（注意：对于目前版本，输入debugger也同样可以工作）。然后您将会进入到调试器的文本界面 - 可用的命令列表可以通过"?"命令获得，包括管理断点和诸如查看op_codes和其他方法中的Ruby源代码这样的特性。

比起那些依靠trace方式调试的Ruby实现（不论这些实现的速度有多快），全速调试器都使得Rubinius具有了独特的优势。同样值得注意的是：除了整个yield_debugger指令使用了一些C代码，绝大多数Rubinius调试功能都是内建的。

您尝试过Rubinius了吗？您是否了解应如何有效利用Rubinius清晰可见的内部结构，例如可以在运行时刻访问并修改字节码、查看调用栈？

另：查阅InfoQ之前关于Rubinius的相关报道。

查看英文原文：Inside the full speed Rubinius debugger

• 更早的 >