平台无关的编程语言如Java和C#已经形成了相当大的市场，尤其用于基于网 络的应用。通常，用这些语言编写的程序首先编译成用称为字节码的平台内核 分布格式的代码。字节码不能直接在任何平台上运行。必须将它们解释成特定 平台能理解的指令。例如，Java程序，是由Java虚拟机(JVM)将字节码解释 成平台理解的指令(对于C#程序，公共语言基础结构(CLI)是虚拟机)。然 而，JVM的解释通常给字节码的执行强加了不可接受的性能损失，因为要求很 大的运行时间开销。已经设计了实时(JIT)编译器来改进JVM的性能。它在第 一次调用该方法之前，将一个给定方法的字节码编译成平台的本地代码。该方 法的本地代码存储在存储器中，并且任何后面对该方法的调用将由这个较快的 本地代码来处理，代替由较慢的JVM的解释来处理。
对于具有小存储器印迹的设备，特别是移动设备，由JIT编译器产生的本地 代码太大了，不能适合于存储器。结果，许多这类设备的制造商选择不使用JIT 编译器并且因而失去由JIT编译器带来的性能好处。为了让小存储器设备使用 JIT编译器，必须使用存储器管理机制，它有效地回收利用由其它本地代码占 用的存储器空间。当将这类存储器管理机制应用于存储本地代码的代码高速缓 存时，通常将它们称为代码高速缓存管理(CCM)机制。
一般作为动态优化问题的一部分讨论CCM的问题，如在关于编译器与计算机 体系结构之间的交互的第六次年会(Sixth Annual Workshop on Interaction between Compilers and Computer Architectures)(INTERACT’02)的年报中 K.Hazelwood和M.D.Smith的“Code Cache Management Schemes for Dynamic Optimizers(用于动态优化器的代码高速缓存管理模式)”中讨论的。一个CCM模 式是完全高速缓存转储清除(Full Cache Flush)(FCF)。在这个模式下，即 将到来的代码开始从最低的地址向较高的地址填充高速缓存。一旦高速缓存 满，在高速缓存中的所有代码被转储清除并且填充过程再次开始。另一个CCM 模式是最久远访问的转储清除(Least-Recently Accessed Flush)(LRAF)， 它在高速缓存满时转储清除最近没有访问过的代码。当由最久远访问的代码释 放的空间不足以保存即将到来的代码时，转储清除毗邻的代码，使得可以为新 代码产生足够的连续空间。另一个CCM模式称为最少访问的转储清除 (Least-Frequently Accessed Flush)(LFAF)。LFAF的思想实质上与LRAF相 同，除了最少访问的代码是要转储清除的第一候选。还有另一个CCM模式是最 久远创建的转储清除(Least-Recently Created Flush)(LRCF)，其思想是在 代码高速缓存中的代码以插入它们的相同顺序来代替。还有另一个CCM模式是 最大元素转储清除(Largest Element Flush)(LEF)，它首先转储清除最大的 代码(并且如果新代码需要更多连续空间则转储清除毗邻的代码)以最小化转 储清除数量。还有另一个CCM模式是最适合元素转储清除(Best-Fit Element Flush)(BFEF)，它首先转储清除大小刚好足够的代码(如果不精确相同，则 为大小大于新代码大小的最小代码)用于新代码。
当将CCM模式应用于用JIT编译器运行平台无关程序(例如，类似Java的 程序)的小存储器系统时，代码的重新编译率会增加。这是因为后面的代码可 调用已经作为CCM的结果被转储清除的先前编译的代码。用于用JIT编译器运 行类似Java程序的CCM模式的一个目标是提高存储器使用效率而不显著增加 重新编译率。另一个目标是减少由CCM模式招致的开销，因为大的开销可以减 缓处理速度，并且因而损害由CCM模式带来的可能的性能改进。然而，如上面 提到的目前可用的CCM模式，可以产生较高的重新编译率和/或大的开销，尤 其对于运行类似Java的程序的小存储器系统。因此，需要一种可以减少重新 编译率而不增加很多开销的更有效CCM模式，以改进运行类似Java的程序的 小存储器系统。
附图说明
本发明的特征和优点通过下面本发明的详细描述将变得显然，其中的附图 是：
图1按照本发明的一个实施例示出使用用于Java程序的基于优先权的代码高 速缓存管理机制的示例系统的高层框架：
图2是按照本发明的一个实施例的一个处理过程的示例性流程图，在其中在 运行平台无关的系统中执行基于优先权的代码高速缓存管理：
图3是按照本发明的一个实施例基于代码高速缓存管理机制和代码垃圾收集 器的高层功能方框图；
图4是按照本发明的一个实施例的一个处理过程的示例性流程图，在其中更 新继续存在的方法计数器；
图5是按照本发明的一个实施例的一个处理过程的示例性流程图，在其中基 于优先权的代码高速缓存管理是通过基于继续存在的方法计数器值的选择性 垃圾收集来进行的；
图6按照本发明的一个实施例示意性示例继续存在的代码压缩，作为进行基 于优先权的代码高速缓存管理的一种方法；以及
图7按照本发明的一个实施例示意性示例直接与间接调用在继续存在的代 码压缩(作为进行基于优先权的代码高速缓存管理的一种方法)上的不同影响。
详细说明
本发明的一个实施例是一种方法和设备，用于有效管理计算系统中的代码高 速缓存，特别是用于用JIT编译器运行平台无关程序的小存储器计算系统。本 发明可用于增强这样一个计算系统的性能，通过保证在代码高速缓存中存在足 够的空间用于新代码而不显著增加重新编译率或招致很大开销。基于选择性代 码垃圾收集机制的基于优先权的CCM可用于选择性地回收利用由失效的方法占 用的空间。经历CGC后继续存在的方法称为继续存在的方法。当执行选择性CGC 时，不是所有失效的方法被视为垃圾。那些具有在以后被程序重新使用的高概 率的失效的方法被保存在代码高速缓存中而没有被CGC机制收集。一个方法在 将来被程序重新使用的概率可由该方法的继续存在的方法计数器的值来测量。 只要代码高速缓存的条件保证选择性CGC，则所有失效的方法按照它们的SMC值 排序到一个队列中，其中SMC值相应于最低概率的方法处在队列的底部。CGC从 在队列底部处的失效的方法开始，直到对代码高速缓存中空闲空间的要求满 足。
基于选择性CGC方法的基于优先权的CCM机制可以提高代码高速缓存的使用 效率。该机制不仅能减少方法的重新编译率，而且在运行时间只招致很少的开 销。具体地说，该机制使运行类似Java语言的小存储器系统能够使用JIT编译 器来改进性能。
在说明书中引用的本发明的“一个实施例”和“一个实施例”指结合实施例描 述的一个特定的特征、结构或特性包括在本发明的至少一个实施例中。因而， 在整个说明书中各处出现的短语“在一个实施例中”的出现不必都引用同一个实 施例。
图1按照本发明的一个实施例示出使用基于优先权的代码高速缓存管理用于 Java程序的高层框架。核心JVM 110接受平台无关的Java字节码，并且随后或 者将字节码解释成底层处理器能理解的指令，或者通过使用JIT编译器120将字 节码编译成存储在代码高速缓存中的本地代码。核心JVM具有执行机制以执行 本地代码或经解释的字节码。正常通过存储在代码高速缓存中的JIT编译的本 地代码执行Java代码比通过JVM解释的指令执行相同的Java代码要快得多。这 就是为什么大多数JVM使用JIT编译器的原因。然而，本地代码占用代码高速缓 存中的存储器空间。在许多具有大代码高速缓存的系统中，将本地代码存储在 代码高速缓存中不是问题。然而，对于具有小代码高速缓存的系统，在代码高 速缓存的空间是宝贵的。这样一个小代码高速缓存的有效使用是所希望的。
代码垃圾收集器140可用于回收利用由代码高速缓存中的失效方法占用的空 间。如果代码垃圾收集器发现方法无效，就回收利用这些方法的空间，然而， 某些方法的重新编译率会很高，因为可能在以后需要某些失效的方法。JIT编 译的本地代码可以提高Java程序执行速度的一个原因是一个方法的本地代码 一旦编译就可以重新使用。如果CGC技术的使用导致高重新编译率，则会失去 使用JIT编译器的一个好处。因此，使用代码垃圾收集器迅速地收回失效的方 法在代码高速缓存中占用的空间不足以提高代码高速缓存使用效率。本发明的 一个目标不仅要收回由失效的方法在代码高速缓存中占用的空间，而且还要减 少普通重新编译率。
基于优先权的CCM机制130可用于提高代码高速缓存的使用效率，并且减少方 法的普通重新编译率。基于优先权的CCM机制判定哪些失效的方法比其它失效 的方法具有作为垃圾收集的较高优先权，基于每个失效的方法在将来被重新使 用的概率。具有较重新使用概率的失效的方法具有经历CGC后继续存在的较高 概率。一个方法的重新使用概率可由该方法的SMC值来测量。对于方法的SMC值 如何与方法的重新使用概率相关是一个设计选择。在一个实施例中，方法SMC 的较大值可相应于较高的方法重新使用概率。在另一个实施例中，方法SMC的 较小值可相应于较高的方法重新使用概率。方法SMC的值可在每个基于优先权 的CCM会话期间更新。方法SMC的值也可在每次重新编译方法时更新。在一个实 施例中，基于失效的方法的SMC值，失效的方法可排序到一个队列中，使得具 有最低重新使用概率的失效的方法呆在队列的底部。代码垃圾收集器140可从 底部向上开始回收利用失效的方法，直到代码高速缓存空间要求已经满足为 止。
图2是按照本发明一个实施例的一个处理过程的示例性流程图，在其中基于 优先权的代码高速缓存管理是在运行平台无关程序的系统中执行的。在块210， 平台无关的字节码(通常在Java程序的.class文件中)可由JVM接收并传递给 JIT编译器。在块220，JIT编译器将字节码编译成本地代码。本地代码最初可 存储在缓冲器中并且等待传送到代码高速缓存中。在块230，基于优先权的CCM 可由基于优先权的CCM机制执行，使得代码高速缓存可以基于每个方法的优先 权而被有效管理，保证代码高速缓存中的空间更有效的使用。还是在块230， 由JIT编译器产生的本地代码也可由基于优先权的CCM机制从缓冲器传送到代 码高速缓存。按照本发明的另一个实施例，块220和230的顺序可以交换。例如， 如果接收到的字节码非常大并且它的相应本地代码太大而不能适合于缓冲器， 则本地代码不得不直接放到代码高速缓存中。在这种情况下，基于优先权的CCM 可在将字节码编译成本地代码之前执行，使得在代码高速缓存中有足够的空间 用于经编译的本地代码。
图3是按照本发明一个实施例的基于优先权的代码高速缓存管理机制和代码 垃圾收集器的高层功能方框图。代码垃圾收集器140包括至少两个组件：根集 合扫描机制310和垃圾回收机制320。这两个组件可在功能上或在时间上交错， 并且回收技术可依赖于由根集合扫描机制执行的垃圾检测技术。
根集合扫描机制区分有效的方法与失效的方法。在启用代码垃圾收集器时， 活动的方法被视为有效的。可基于堆栈信息来确定方法的活动性。只有有效的 方法具有存储在堆栈中的信息(例如，返回指针，变量等等)。这些活动方法 形成一个基本的根集合。存在两种方法来确定有效的方法的最终集合。这两种 方法产生两种不同的有效的方法的最终集合：宽集合和窄集合。有效方法的宽 集合包括从根集合中的方法能够到达的所有方法，在来自根集合的指针的任何 有向路径上的所有方法。有效方法的窄集合包括仅在基本根集合中的方法。在 有效方法的最终集合之外的任何方法被视为失效的并且可以被回收利用。按照 定义，宽集合可包含比窄集合更多的方法。
关于宽集合的一个可能的问题是存在许多从根集合能到达的方法并且所得 出的有效的方法的数量会太大。结果，CGC不能在代码高速缓存中释放出所需 要的空间。对于小存储器系统，与大存储器系统相比，这个问题会更经常发生。 最坏的情况是CGC可能没有用处，因为代码高速缓存充满了由宽集合定义的有 效的方法并且没有空间可以回收。对于小存储器系统，更希望使用有效的方法 的窄集合。窄集合的一个缺点是开始时重新编译率会很高，因为由根集合中的 方法指向的方法被视为失效的并且在CGC期间会被回收利用。基于优先权的CCM 终于克服了这个缺点。如果一个方法在开始时不适合被回收利用，则该方法的 SMC值将改变(增加或减少)，产生该方法的增加的概率。换言之，该方法将 在以后具有较小的被回收利用的概率。因此，对于小存储器系统，有效方法的 窄集合定义比有效方法的窄集合定义会运行得更好。
垃圾回收机制320回收失效的方法占用的空间，基于由根集合扫描机制提供 的有效的方法的最终集合。一般失效的方法不是定位在一起的，并不占用代码 高速缓存中一个连续的区域。它们可能分散在代码高速缓存的不同区域中。回 收会导致代码高速缓存中的碎裂。存在各种回收技术，一般落在两个类别之中： 移动和不移动回收。移动回收技术不仅回收失效的方法占用的空间，而且还将 有效的方法移动到代码高速缓存中的连续区域中，如图6所示。继续存在的方 法615、630、645和650被移动到与在代码高速缓存一端的方法605连续的区域， 使得在移动后空闲空间也是连续的。相反，不移动回收技术，只是回收失效的 方法占用的空间，而不将有效的方法移动到代码高速缓存中连续的区域。不移 动回收技术更有可能在代码高速缓存中产生碎片。代码高速缓存中有了碎片， 在代码高速缓存中的可用空间实际上会小于总的空闲空间，因为小碎片不适合 于新代码。例如，图6中被回收的空间610可能不能由大小大于空间610的大小 的新代码重新使用，如果有效的方法没有被移动。
然而，如果方法是位置相关的，则将有效的方法移动到代码高速缓存中的新 区域，这会引起问题。一种解决这类问题的方法是要求JIT编译器产生位置无 关的代码(PIC)。可使用间接的调用来产生PIC。图7示意性例示了直接与间 接调用对移动垃圾回收技术的不同影响。在直接调用的情况下，调用被移动的 有效的方法(例如F9)的每个指令(例如，指令710、720和730)必须知道方 法的新位置(例如760)。然而，在间接调用的情况下，调用被移动的方法(例 如F9)的每个指令(例如710、720和730)不需要知道方法的新位置(例如760)。 相反，调用指令如710只需要知道被调用方法如F9的指针。指向方法(例如740) 的指针必须知道方法的新位置(例如760)，如果方法被移动。使用间接调用 是产生PIC的一种方法；还有其它产生PIC的方法。即使产生PIC在某种程度上 是不可能的，也可使用重新定位表来修补该方法以反映方法的新位置。
使用移动垃圾回收技术，与不移动垃圾回收技术相比，可使代码高速缓存在 CGC之后更有用。移动垃圾回收技术也会招致较大的运行时间开销。本发明或 者与移动或者与不移动垃圾回收技术一起工作。
如图3所示，基于优先权的CCM机制130可包括三个组件：SMC更新机制330， SMC 340，和继续存在的方法确定机制350。SMC 340跟踪在运行时间重新使用 一个方法的概率。SMC更新机制330更新SMC的值。继续存在的方法确定机制350 确定那些失效的方法可基于由根集合扫描机制提供的信息、由SMC 340提供的 失效的方法的SMC值和其它因素来回收。其它因素可满足触发条件来触发CGC和 满足停止条件来停止CGC。触发和停止条件可以是一个阈限，它可于代码高速 缓存的空闲空间大小或者代码高速缓存中的继续存在的方法的数量。例如，只 要代码高速缓存的空闲空间大小落到低于下限(即满足触发条件)就可触发 CGC，并且只要代码高速缓存的空闲空间大小超过上限(即满足停止条件)就 可停止CGC。同样，只要在代码高速缓存中的继续存在的方法数量超过上限(即 满足停止条件)就可触发CGC，并且只要在代码高速缓存中的继续存在的方法 数量落到低于下限(即满足停止条件)就可触发CGC。在CGC之后，继续存在的 方法的集合包括有效的方法和那些没有被回收的失效的方法两者。
SMC更新机制330更新方法SMC的值，基于由JIT编译器120和继续存在的方法 确定机制350提供的信息。由JIT编译器120提供的信息包括一个方法是否首次 被编译并且先前被回收利用的方法是否被重新编译。在一个实施例中，当一个 方法被重新编译时，方法SMC的值可增加一个数值。由继续存在的方法确定机 制350提供的信息包括一个方法在基于优先权的CCM期间是否是有效的。在一个 实施例中，当该方法在基于优先权的CCM期间是有效的，方法SMC的值可增加一 个数值；否则，该方法的方法SMC的值可减少一个数值。SMC值帮助在失效的方 法中确定相对的重新使用概率。因而，可颠倒增加和减少操作来达到相同的结 果，例如，方法SMC的值可在该方法被重新编译时减少一个数值。因不同事件 而改变的实际值可相同或不同。在一个实施例中，一个方法SMC的值可增加2， 只要该方法被重新编译，而在基于优先权的CCM期间只要该方法是有效的则可 减少1。可限制增加和减少量，使得任何SMC的值将落在预定义的范围内。
图4是按照本发明的一个实施例的一个处理过程的示例性流程图，在其中更 新SMC的值。在块410，方法是由SMC更新机制的初始化组件标识的。在块420由 初始化组件为所标识的方法给SMC设置一个初始值(例如零)。在块430，作出 是否重新编译先前被回收利用的方法的决定。如果方法被重新编译，则方法SMC 的值在块440增加一个第一数值；否则，在块405作出在CGC期间方法是否是有 效的另一个决定。如果方法在基于优先权的CCM期间是有效的，则方法SMC的值 增加一个第二数值；否则，方法SMC的值减少一个第三数值。第一、第二和第 三数值可相同或不同。在一个实施例中，第一数值可以是5，第二数值可以是1， 而第三数值可以是1。另外，块430和450的顺序可颠倒，或者可现时进行这两 个块。在块480，可更新方法SMC的值并且进一步与预定的上下限比较以保证值 落在预定的范围内。SMC值的更新可以是一个连续的过程。因而，在块480，需 要连续的检查来监视在块430和450中设置的任一条件是否满足。在所有块处的 处理是由SMC更新机制执行的。
图5是按照本发明的一个实施例的一个过程的示例性流程图，在其中基于优 先权的CCM是通过基于继续存在的方法计数器的选择性垃圾收集来进行的。在 块510，JVM开始运行一个程序。在块520，由继续存在的方法确定机制350作出 是否已经满足基于优先权的CCM的触发条件的决定。如果已经满足触发条件， 则在块530，继续存在的方法确定机制指示垃圾回收机制320进行选择性CGC。 在块550，由继续存在的方法确定机制作出是否已经满足基于优先权的CCM的停 止条件的决定。如果已经满足停止条件，则在块550，停止选择性CGC，并且JVM 继续运行程序；否则，在块530进行更多的选择性CGC。在一个实施例中，可组 合块530和550。继续存在的方法确定机制需要连续地监视，如果满足了优先权 CCM的触发条件。
尽管参考图1-7中的块和流程图描述的了本发明的示例实施例，但本领域的 熟练技术人员将容易地意识到，许多实现本发明的其它方法可供替换地使用。 例如，执行流程图中的块的顺序可改变，和/或在所述的块或流程图中某些块 可改变、消除或组件。
为显示本发明的好处，使用Java编程语言、JVM和用于本地代码的代码高速 缓存来描述本发明。实际上，不是要将本发明限制在Java编程语言、JVM和用 于本地代码的代码高速缓存中。本发明可以用于其它平台无关的编程语言、其 它系统和/或其它高速缓存系统，以提高高速缓存管理的效率并因而改进整个 系统的性能。
在前面的描述中，已经描述了本发明各个方面。为了说明的目的，描述了特 定的数字、系统和配置，以便提供对本发明的完全理解。然而，本领域的熟练 技术人员在获得本发明的好处后，可在没有这些特定细节的情况下实践本发 明。在其它实例中，众所周知的特征、组件或模块被省略、简化、组合或分离， 以便使本发明更清晰。
本发明的实施例可在任何包括硬件和操作系统的计算平台上实现。
如果本发明的实施例用软件实现，则软件可存储在可由通用或专用可编程处 理系统读取的存储介质或设备(例如，硬盘驱动器，软盘驱动器，只读存储器 (ROM)，CD-ROM设备，闪存设备，数字多功能盘(DVD)，或其它存储设备) 上，用于在存储介质或设备由处理系统读取以执行在此描述的过程时配置和操 作处理系统。本发明的实施例也可考虑作为机器可读存储介质来实现，配置为 由处理系统使用，其中这样配置存储介质使得处理系统以特定和预定义方式来 执行在此描述的功能。
尽管已经参考说明性实施例描述了本发明，但不要在限制意义上解释该描 述。说明性实施例的各种修改以及本发明的其它实施例，相信是在本发明的精 神和范围之内的，对于本发明所属领域的熟练技术人员，这是显而易见的。