Mark Lam has been a virtual machine engineer in the JavaME CDC team at Sun Microsystems for over 6 years. Before joining Sun, he was a real-time embedded systems developer for 6+ years, working on application frameworks, graphics systems, networking protocols, game development, and fault tolerant systems amongst other things, on devices ranging from 64KB 8bit uControllers to 32-bit RISC machines.
原文URL：http://weblogs.java.net/blog/mlam/archive/2006/11/c_further_with.html#more
我已经谈论过一些关于CVM的深奥的知识，并且我想是时候说一些真正的技术了。因此，我花了昨天大部分的时间来制作了一个关于CVM的结构图来向你展示它的结构，但它比我想象的要长。结果，昨天没有放上blog。今天有希望能把它完成，并在周一补写到blog。它看来像放在坚果里的CVM。
另外，我使用 InkScape 来存放我的CVM结构图，我不知道这是不是最好的，但它适合做这个工作。因此，我想我在这给一个说明万一其它人也在找这样的工具。我使用 InkScape 是因为我在SVG里渲染CVM结构图，因此我需要缩放它来匹配任意你需要的解决方案而不用考虑细节。但我也发现我的浏览器不能快速的显示SVG格式的图片（可能我没有导出正确的格式），如果有人发现你的浏览器不支持SVG格式，请告诉我，我会把它转成PDF格式。
顺带说一下，我想感谢留言的2位朋友，这让我知道我没有对牛弹琴。
为什么用C来写CVM
这是C和C++之间的选择？像我在前面文章里指出的一样，CVM的体系非常匹配对象类。使用C++已经是一个选择。我们选择C的原因是因为C编译器比C++编译器在嵌入式领域有良好的实用性。我提醒你可移植性是CVM的一个主要目标，也是为什么它在嵌入式领域能够生存的原因。有代表性的，当硬件更新，它总是和C编译器一起的，而C++编译器可能会或者可能不会更新。我们希望Java平台能够在任何平台运行，事实上这和选择C是一样的。
第二个要注意的地方， 我们发现一些C++编译器总是生成非常低效的代码在一个周期（2到3个周期），这对任何嵌入式软件都是不好的。现在，在你跳到结束前，我不认为C++原因本身是低效的。私下的，我是一个C++的爱好者，我知道它怎样让你写出真正一流和高效的代码（像计算编译器协作）。或者臃肿的代码。我的建议是在这个时候，一般的人们不要过多的关心C++在给了你多少的工具链（和C比）。不要说任何C++比其它好很多的话。事实上，C++有一个坏名字，我想这非常不幸。
照顾好自己，7年前，CVM就决心做些什么。低效的代码生成在3，4年前被察觉，或许这些关于实用性和效率的问题已经被修复了。
其它我想要说的关于便携性和性能的在下面
便携性的一个注解
我在前面提过，CVM的代码是由在shared目录里最高的代码密度组织成的（相对于特殊平台）。给你一个特别的概念，在2003年，我们在shared目录和platform目录为动态适应编译（JIT）测量代码线作对比。在这种情况下，shared部分包括 RISC层在 portlibs 目录，开始共享代码的比率是80-90%，保留CPU和OS的特别代码。大多数由汇编代码组成的非共享代码生成的特定CPU体系的常规程序。如果我们考虑VM空闲因素，这个对共享代码的比率会更高。我们没有实际测量这个，但如果我乱猜的话，我说他会上升到95%。
一个汇编程序非常小的子集作为编译器代码和VM休眠之间的过渡是非常必要的。保持所有的焦点在特殊CPU体系的优化上。一个好消息是，除了少量的粘合代码外，CPU特殊的优化代码都是可选的。这意味着你不需要为JIT执行所有的命令来保证操作的正确。代码的共享部分（小范围汇编代码）对性能的提升仍然有重大的意义（50~70%的提升）。附加的优化根据需要或VM开发者的时间
另一个要注意的问题是关于CVM体系的。一个 VM开发者必须能够完成一个CVM的完全最小效果的移植，但仍然会得到许多性能上的原因。那么，如果时间允许，尽可能的调整和优化以得到附加性能的提升。这就是为什么我们大多数的更新和提升在用C写的共享代码中。
提升仅仅是一个CVM build的解释（比如禁止JIT），它会带来少许的成就。这儿只有一个常规汇编程序需要编写。这个程序通常被称为“本地调用（invokeNative）”，它的责任是成为本地代码和解释器的粘合器。它的全名是“（CVMjniInvokeNative）”。在这儿有例子。如果你做linux移植（或其他系统），那么你会有个很好的开始。如果不是，你将执行HPI，但你可以使用其他已经存在移植的相关代码。
总的说来，CVM容易移植不仅仅依靠减少必须进行的移植工作量。（共享代码对平台特殊代码的高比例），它的目标总是允许移植成就相对于现阶段。对开发者来说，为了适合开始时间它是很容易分离的。它总是增加系统的易测性。
性能的一个注解
我的职业教育背景是硬件。因此，随时我听到的关于某些软件的创新都会让我开始提高系统的性能。怎样的软件能使硬件超过它现在的性能运行的更快？答案是未知的。
任何软件能取得的最快速度是作为运行在硬件上的命令或限制。无论如何，硬件靠自己来提升性能不是那么容易的。他让软件指挥（direct）硬件来有效的工作。“指挥（direct）”翻译成管理成本（management cost），我们通常不喜欢为不必要的东西买单。因此，用软件来提升性能相对更好的硬件是一个很好的主意。这让我们花费较少的代价来取得更多的性能。
管理成本（management cost）是影响代码的移植性和可维护性。代码的可维护性、易移植性这个话题不需要太多的解释对于那些每年有很多维护经费的开发者。
象CVM代码的可移植性、可维护性总是非常重要的。现在phoneMe开源了，每个人都能够贡献bug 修改（fixes）和增加（enhancement）。我想提醒大家代码需要坚持维护，这对每个人都非常重要。如果开源的一段代码没一个人能读懂是怎么一回事？？这可能用密匙来加密。我说丢弃因为代码恢复往往是恢复甚至是有时作者已经通过。（完全翻不通：After all, how open-source is a piece of code if no one can understand it? It might as well have been encrypted with the secret key thrown away. I say thrown away because unmaintainable code also tend to be unmaintainable even to its creators once some time has passed.）
关键点是我们不需要牺牲可维护性在性能上。这是一个谬论，当我们不能在同一时间拥有高性能和可维护的代码。非常难得的是有异常在我们可维护的代码中。无论怎样，我们应该包含损害不至于通过基础代码影响本地化。（The point is that we shouldn't sacrifice maintainability in the name of performance. It is a fallacy to think that we can't have both high performance and maintainable code at the same time. Very rarely will there be an exception where we might have to sacrifice some maintainability. Even then, we should try to contain the damage so that it is localized and not wide spread across the code base.）
这是CVM的解释程序循环用C写而不是汇编的一个原因。这的确可以用汇编来写，但代价是巨大的，在你移植和维护的时候。在实践中，我们发现CVM用C写的解释程序循环的效率和优化的汇编循环差别不大，但移植性和可维护性很好。
结束
谢谢大家听我讲了这么多，下次将介绍CVM的世界，子系统，数据结构，还有一张大图片
祝有美好的一天！
2735
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
