云风的 BLOG: 给脚本加入字符串类型

最近的工作是给虚拟机加上字符串类型的支持，并让编译器可以生成相应的 bytecode 。思路很简单，就是按 lua 的方式，把所有源码中相同的字符串合并，在 bytecode 中只保留一份。所有提到这些字符串的地方直接对其引用。bytecode运行时，产生的任何新的字符串都会产生新的副本。垃圾等到 gc 时回收。

想起来容易，实现起来还是颇为麻烦的。

首先要解决的是，bytecode在内存时，所有提到的 string 都可以直接是一个地址。但是 bytecode 在没有加载到虚拟机前，任何绝对地址都是不允许的。所以加载 byecode 的过程，不再是简单的内存复制。对 string 做操作时，希望尽量是 0 消耗，不希望出现任何惰性初始化的过程。

现在的解决方案是，扫描源码的过程（我的编译器是一遍扫描的），碰到任何的字符串都被编号。在函数定义中，直接把编号压栈。在非函数定义时，则按编号在一个特定的局部table中取出来。非函数内代码，操作 string 是有消耗的，有一次取 table 的过程。不过因为局部 table 读操作也是一行 bytecode 所以空间消耗没有增加。在注册函数时，扫描函数体的 bytecode 转换所有的编号到绝对地址，待到调用时，就是 0 消耗了。

把全部源码编译完后，自动生成一个注册函数，将所有提到的 string 注册到虚拟机中。最后在生成的 bytecode 最前插入一行调用这个自动生成函数。

自己的方案简述完了。至于虚拟机内的处理也是比较麻烦，不过只是麻烦而已，代码还是一样的要写下去的。
这里闲话几句 java 。

java 中的 string 在虚拟机实现的时候跟 lua 这个方案类似。但是许多 java 程序员并不太知晓。一个事件是从李维那听来的，据说是 tomcat 4 里的问题(我有点记不清版本了)，在一个内循环中使用了 string += 的操作。结果这个操作被运行了很次后产生了大量的垃圾，致使 gc 频繁调用。

另一个事件是听我的同事说的，说我们公司另一个主用java做项目的部门的人，在一个项目中用到了持久化的操作。在做 codeview 的时候，我那个同事置疑其效率。然后就有人回去做测试，得出的结论是，java 在<strike>持久化</strike> 序列化 string 的时候效率颇高，几乎没有效率问题。当时听到这里我就笑了，虽然我没写过 java 程序，但是直觉告诉我，某人一定用相同的字符串，放到一个循环中去持久化了 :D 难怪事后得出的结论是，java 持久化不仅效率高，还带有压缩功能。

12月8日补遗：
下面有朋友谈到应该是序列化而不是持久化，吾以为然也。就这个问题上看，我们公司的 java 程序员想用这个功能，把一组 string 写到硬盘上，做的是一个持久化操作。作为 java 程序员的一种共性，他们不会去考虑 IO 操作的消耗，序列化数据的消耗等。但是转述这个故事和听故事的我，都是 C++ 程序员，第一反应却是性能的问题。(当时这个是用在一个性能要求很高的应用中)
至于 string += 的操作，对虚拟机实现用一定了解的程序员会很敏感于内存消耗。当时李维举这个例子是想说明有些 java 程序员太不关心 java 的语言细节和性能。当然正确的做法，java 老手都应该明白，我这个不懂 java 的 C++ 程序员也可以猜到。但是错误发生在 TomCat 正式发布版中的确不应当。