lua 近期的一个 bug
在 lua 的 maillist 上最近报告了一个 bug 。
看起来问题比较严重，因为稍具规模的 lua 程序都可能因此而出现问题。最近两周，我和我的同事都比较关注这个问题，并对 lua 的源代码做了相关的分析。
Roberto 作为 lua 委员会三巨头之一，在 mail 中已经表示追踪到 bug 的起因，但暂时还找不到合适的解决方案。直觉告诉我，这不会是一个简单的问题。如果容易修正的话，patch 早就有了，而不会只是发一个 bug report 而已。所以我们也并未尝试自己去修补这个 bug ，可以做的可能只有等待。
近期的一些讨论表明，这个问题出至于 lua 的 parser 在处理常数时做的一些简单优化。类似 1+2 这样的代码在编译器有可能被编译成常量 3 。
算法本身没有错，错在 lua 的一些优化处理上。
当一个 chunk 中常量少于 256 个时，lua 在生成 VM 指令时，会将常量编号直接生成在指令内；而超过 256 个常量，就必须依赖堆栈。lua 的 parser 是一次扫描的递归下降算法。在做这种常量合并（编译期运算）时，每一个常量都不能立刻生成代码，而要看它是否可以和下一个常量合并。一次扫描导致了在 256 这个临界点时不太好处理两种生成算法的区别。
我自己去年也写过简单的编译器，同样是一次扫描的递归下降算法。对于这样的 bug 的出现深有感触。
我想，这也是一种提前优化的体现吧。越是复杂的程序，执行效率越是来之不易。
3月26日补：
Comments
Posted by: cj | (4) March 5, 2010 10:24 PM
Posted by: Linker M Lin | (3) March 8, 2007 12:50 PM
Posted by: ywchen2000 | (2) February 28, 2007 03:27 PM
Posted by: ecurb2006 | (1) February 17, 2007 06:36 PM