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/introduction_to_1.html
如果你现在在阅读这篇文章，那么你对Sun通过PhoneMe工程来开放J2ME源代码有所了解，如果不是，点这里了解关于PhoneME。
一些背景信息
开放我们代码的目的是允许你能够访问它，学习它，并有可能贡献你自己的改进。现在你已经可以访问一个代码链了，但访问和能够理解以及贡献有很大区别，它需要一些特别的知识。就大部分来说，只有Sun的雇员和少数例外（使用我们技术的公司的一些核心虚拟机工程师）能够这样做。我提到的知识包括：代码规范、术语表、设计原理、代码组织和设计权衡等等。但我相信你有足够的智慧来及时的领会这些，但我想这不是你在这个项目里开始的地方。
因此，我会就这些主题写一系列的文章（从这篇开始）来使我们的交流变的更容易，使每个人都能得到很到的资料而不用浪费时间在平常的事情上。我也会写一些像“怎样确定子系统的工作”之类的技术文章当我有灵感的时候。我允许你留下注释来告诉我你想我讨论的主题，或是你想我阐述明白的事情。在我选择文章主题的时候会考虑这些。
在我开始前，你会问我如果来共享这些知识（为什么你要相信我的确知道我在谈论什么）。因此，关于我：工作在PhoeMe Advanced项目的虚拟机小组，负责建立和维护虚拟机。我从CDC1.0发布前就在这个小组工作。因此我和这些代码已经工作了很长的时间。在我们小组工作的过程中，我们不会正式的把虚拟机按我们工作的分成部分。我们基本会在任何需要的地方做必须的工作。因此，每一个虚拟机工程师的代码知识都是全面的。当然，我们每个人都有比其他人熟悉的领域。我需要指出我是一个虚拟机工程师（相对于类库工程师），我的专业技能集中在虚拟机和一些核心系统代码上。我也有一般的标准类库知识，但和他们比我不是专家。我们每个工程师都有自己的领域。因此我会写关于PhoneMe Advanced虚拟机的文章，因为这是我擅长的领域。
好的，让我们开始我们的第一个主题。
The meat（不知道怎么翻译了）
前面，我说过深奥的知识我们会很少涉及，甚至在使用我们技术的用户里面。原因是这些用户很少有需要和动机去修改我们称作 共享代码 的部分。但现在这不会维持太久了。有太多的创新和特点需要在我们的代码里实现，这部分历史只限于Sun的雇员。我们的用户，在其他方面，需要关注的是我们称为 HPI （Host Porting Interface）的代码部分。点这里察看CDC移植指南，它会告诉你 HPI 的细节。实际上，在代码里有 HPI 文档如果你知道在哪能看到的话。你也可以从其他网页上找到一些有趣的文档。
设计原理（Design Philosophy）
虚拟机被设计成高移植性，尽可能的减小代码以用于尽可能多的平台。这是虚拟机的基本规则。
在共享机制下保证尽可能多的普通代码被减小。只有依靠硬件和OS的代码在共享代码以外。这些和硬件和OS捆定的指那些 目标或平台特殊的代码。点这里察看PhoneME Advanced src 列表。这有几个特殊的例子， arm ，linux ，linux-arm 文件夹。Linux 目录包含那些所有在linux移植下用到的代码。这个通常有一些 HPI 执行被调用，从 share 目录下。
Linux-arm目录包含附加的用户定制的全部或重载的执行在linux目录。这些用户定制只能对于linux arm 移植。
arm 目录包含针对arm的特殊代码，通常，他们看起来是一些有效函数（有些情况它们是汇编代码）。它们能被不同的arm平台移植调用。
你在OS文件夹（如linux）下可以找到代码同等的共享文件夹（包括它们的子目录），紧随其后的是OS－CUP（例如： linux-arm）和CPU（如 arm）。这些事实表明了VM是多么的可以移植。移植成果通常只需要执行活修改目标特定的文件（这只是总代码里面的很小一部分）。
我们工作的多数和共享代码里的创新对于目标特定代码只支持我们的决心来对所有移植平台最优化性能是相反的。这样，大部分性能工作都在共享代码里，这对每个移植都有好处。这样我们希望应用的特殊移植都被最优化。为了做到这点，我们常常把它们放在适当的OS－CPU或CPU文件夹下。
我们代码组织的另一方面是代码维护以便于阅读。你会发现共享代码没有用 ＃ifdefs来定制不同的OS和CPU体系。你可以看到＃ifdefs被enabling/disabling VM特性代替。你也可以看到OS，CPU和OS－CPU文件仍然易读，因为他们没有被＃ifdefs用来和其他体系分开。
在src文件夹，你可以看到portlibs文件夹。Portlibs被用来保存那些对多个移植来说通用的，但又不完全能以OS或CPU来区分的代码。一个例子就是工具链（gcc）或库/标准（posix，ansi）。多种的移植（OS和OS－CPU文件）可以选择使用portlibs里适当的代码。
下面一个需要立即的概念是代码组织：根据OO术语，VM有一个父类。这个父类在共享代码里是明确的。每一个特定OS和CPU目标移植的VM是它的子类，通过继承来实现重用。OS代码是共享代码的直接子类。OS－CPU代码是OS代码的子类。CPU文件夹下的代码是可以被OS－CPU类选择使用的有用库。Portlibs 代码是OS－CPU类可以选用的另外的库
总的来说，单个VM对一个给的的平台（OS和CPU）是incamated（这个词不知道什么意思）。无论如何，这是一个来自OS－CPU VM类的示例，它扩展了OS VM类，OS类又扩展了共享VM类。OS－CPU VM类也可以重用那些在CPU和portlibs里被授权的类。
留意，这只是代码组织上的一个概念模型。你会发现在代码里的父和子VM没有参考。这个概念模型表明看来也不完美。你可以发现一些代码关联方面的范围不适合这个提取。是的，这是一个例外，但这个模型是一个普通规则。
这对你意味着什么
当你计划寻找那些完成某些功能的代码，想想这些功能的属于（shared，OS，OS－CPU，or in the CPU or portlibs libraries）。这可以帮助你快速的定位你感兴趣的代码。
你也可以对你想贡献的代码做同样的思考。这个代码组织是VM完成的一个关键因素，它便于移植（这是对移动和嵌入式领域的VM是非常重要的特点）。代码回顾过程对代码贡献也是必须考虑到的。
正如我前面提及的，不遵守这些协定你可以得到一些例外。请不要使用那些偏离协定的借口。作为代替，这些已存在的异常会被相应的修正（如果可能）。或者有一个很好的技术理由，这些情况不适合希望的模型。如果理由充分这些异常是被允许的。
嗨，等一下
所有那些关于可移植的部分听起来都是很好的，但是不是所有的这些层都在性能上有效果？回答是否定的！“不”是对那些我们担心的例子。是不是VM作为高执行蚂蚁它可以内联到任何地方，摆脱压条？可能不会，但我们在可移植和易维护中有一个折中。注意，在实践中，一些执行是可以被忽略的。这就是说，代码不被执行在本地路径。层使用了多样的技术来被执行（那些我在这不会深入）并防止不必要的执行降低与它有关的损失。当然，小组有一些度量来确保这些代码是有竞争力的。
让我来说下其他问题：如果我们不试着挤出每一点可能的性能（因为我们必须权衡我们的设计原理），那么有多少性能是足够的呢？我会在下篇文章回答这个问题。
文章出处：DIY部落(http://www.diybl.com/course/3_program/java/javajs/20090303/157496.html)