文件标题：Java字节码指令计数用于可移植CPU消耗度量

理论计算机科学电子笔记153（2006）57-77www.elsevier.com/locate/entcs使用字节码指令计数作为可移植CPU消耗度量沃尔特·宾德和贾勒·胡拉斯EcolePolytechniqueF′ed′eraledeLausanne（EPFL）计算机与通信科学学院CH-1015洛桑，瑞士firstname.lastname@ep.ch摘要计算应用程序的CPU消耗对于软件开发至关重要，可以检测和消除性能瓶颈（分析）并评估算法的性能（基准测试）。此外，可扩展中间件可以利用资源消耗信息，以便检测客户端组件的资源过度使用（检测拒绝服务攻击）或针对客户端部署的组件的资源消耗向客户端收费。Java虚拟机（JVM）是应用程序和中间件开发人员的主要目标平台，但它目前缺乏标准的资源管理机制在本文中，我们提出了一个工具，Java资源会计框架，第二版（J-RAF 2），它使精确的CPU管理标准的Java运行时环境。J-RAF 2采用了一个独立于平台的CPU消耗指标，即执行的JVM字节码指令的数量。我们解释了这种CPU管理方法的优势，并提供了五个案例研究，展示了不同设置的好处关键词：Java，CPU消耗度量，资源管理，字节码工程，程序转换1介绍资源管理（即，会计和控制资源，如CPU和内存）是软件开发和监控部署的软件必不可少的Profiling允许对程序的资源消耗进行详细分析。它有助于检测热点和性能瓶颈，指导开发人员对程序的哪些部分进行优化。虽然profiling提供了基于单个方法的详细执行统计数据（例如，调用上下文、调用计数器、CPU时间等），标杆1571-0661 © 2006 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2005.10.03258W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）57评估整体性能（CPU消耗、内存利用率等）一个程序。基准测试是一种比较不同算法对给定输入的效率的常用技术。监视服务器系统对于快速检测性能问题和根据工作负载调整系统非常重要。此外，资源管理是防止可扩展中间件中的资源过度使用的先决条件，可扩展中间件允许托管外来的、不可信的、潜在错误的或恶意的软件组件（防止拒绝服务攻击）。在提供商在其服务器上托管客户端组件的场景中，计费可以基于实际资源消耗，即，提供商可以向客户端收取托管组件的资源消耗的费用Java [15]和Java虚拟机（JVM）[19]代表了应用程序和中间件开发人员的主流编程语言和部署平台。然而，目前标准的Java运行时系统缺乏资源管理机制。Java的Profilers基于JVM Profiler接口（JVMPI）[24]，它允许本机代码profiler代理拦截各种事件，例如方法调用。不幸的是，这些profiler代理是用依赖于平台的本机代码编写的，这与Java的座右铭“一次编写，到处运行”相矛盾。更有问题的是，基于JVMPI的精确配置会导致巨大的开销。精确的分析程序运行速度通常会慢10倍以上，在极端情况下，我们甚至经历了4000倍以上的减速（！）由于仿形。因此，基于在JVMPI上的应用不适合于复杂的软件系统，例如应用服务器，并且不可能在生产系统上执行。开发人员花费了大量的时间来提取他们的应用程序的各个部分，以分别对其进行分析，因为由于极端的开销，分析整个系统是不可行的。此外，这些度量通常会影响所分析的应用程序的运行时特性，因此所获得的执行统计信息的价值有限。大多数Java开发人员采用挂钟时间来对他们的算法进行基准测试。然而，这种方法通常给出不精确的结果，这是由于测量粒度（可能是几毫秒的量级），基准测试机器上的变化的工作负载，或者即时编译和垃圾收集的动态。通常情况下，结果是不可复制的，因此，严格地说，不科学。为了获得有意义的结果，通常必须设置专用的机器进行基准测试（没有任何后台过程），输入必须足够大，以显著超过测量粒度，并且基准测试必须多次执行，使用统计方法来巩固重新测试结果W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）5759结果。因此，正确地对Java程序进行基准测试是一项复杂而耗时的任务。Java中的动态类加载和链接简化了可扩展中间件的开发。此外，语言安全（通过类型安全、自动内存管理、内存保护和字节码验证的组合实现）和类加载器命名空间提供了一些基本的机制来隔离软件组件。然而，由于缺乏资源管理机制，不容易检测到拒绝服务攻击。 换句话说，选择Java的一个很好的原因是它有助于构建可扩展的系统，但Java未能带来必要的支持，即资源管理。在本文中，我们提出了一个可移植的Java资源管理框架，称为Java资源会计框架，第二版（J-RAF 2）1，它解决了许多上述Java的缺点。J-RAF 2通过资源管理特性扩展了标准Java运行时系统。由于它是用纯Java编写的，因此可以直接与任意JVM一起使用。到目前为止，我们已经成功地在Java 2标准版（J2SE）、Java 2企业版（J2EE）和Java 2微型版（J2ME）环境中进行了测试。本文的结构如下：在下一节中，我们强调需要可移植的资源管理，重点是CPU资源。我们引入字节码指令计数作为CPU消耗的可移植度量。在第3节中，我们给出了便携式CPU会计和控制技术的概述在第4节中，我们介绍了J-RAF 2成功应用的五个案例研究第5节总结了相关工作，然后在第6节讨论了我们方法的优点和局限性。最后，第7节对本文进行了总结。2便携式CPU管理在下文中，我们关注CPU消耗，因为它是以可移植的方式管理的最具挑战性的资源：人们无法在代码中识别显式的CPU消耗站点，与其他资源相反，它被认为是连续的，这是因为CPU的数量在传统编程环境中很难作为第一类实体进行操作。通常，CPU消耗以秒为单位。在Java中添加CPU管理的流行方法，如JRes [13]，定期访问第1http://www.jraf2.org/60W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）57操作系统获取各个线程的CPU消耗（CPU时间）。然而，这种方法需要本机代码（本机代码库或修改过的JVM），因此阻碍了可移植性。此外，它假设操作系统支持线程以及将Java线程映射到操作系统线程的JVM，这可能并不总是可用的（例如，存在在硬件中提供JVM的Java处理 器 ） 。 更 重 要 的 是 ， 如 果 需 要 详 细 的 执 行 统 计 数 据 （ 例 如 ，profiling）。以秒为单位测量CPU消耗的另一个问题是在一个CPU秒内可以实现的处理量的变化。在基于高时钟速率处理器的现代服务器上，应用程序可以在一个CPU秒内处理大量数据，而在嵌入式设备上，只能完成相同工作负载的一小部分。即使在相同的硬件和操作系统上，不同的JVM版本的性能也可能会有很大的差异。使用CPU秒作为度量来指定“执行合约”（例如，移动代码的CPU限制）是有问题的，因为客户端和服务提供商（将托管客户端代码）可能会使用不同的CPU作为参考。向客户端收取已部署组件的CPU消耗费用也很复杂，因为客户端可能无法确切地知道（并且可能无法验证）他在一个CPU秒内购买了多少有效处理能力。由于这些原因，CPU秒在分布式异构环境中不是一个合适的度量。为了避免这些问题，我们设计并实现了一个完全可移植的CPU管理方案，可以安装在任何现有的Java运行时系统，就像一个普通的Java应用程序。我们利用执行的JVM字节码指令的数量作为CPU消耗的度量。借助于字节码重写技术，Java类文件被转换，以便在执行期间每个线程维护一个字节码指令计数器，指示执行的字节码指令的数量。为此，我们在精心挑选的位置插入会计指令。我们的会计方案的更多细节将在下一节中介绍。我们的字节码转换方案可以应用于应用程序类和库，包括Java开发工具包（JDK）的类由于JVM字节码是可移植的代码格式，因此字节码指令计数器将引用相同数量的已执行字节码指令，而不管转换后的代码在哪个JVM上执行。使用字节码指令计数作为CPU消耗度量有很多优点：• 计算执行的字节码指令的数量不需要任何特定于硬件或操作系统的支持，它可以以完全可移植的方式实现。W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）5761• 由于字节码指令计数直接编码到程序代码中，JVM的即时编译器将优化整个转换后的程序，包括会计代码。因此，可以减少CPU管理的开销。• 独立于执行平台，给定的程序将计算相同的CPU消耗值。• CPU消耗统计数据在不同的平台上是完全可复制和可比较的。因此，利用已执行字节码指令的数量作为度量标准，对于在所有类型的Java平台上提供单个CPU管理工具、构建可靠且充分有效的配置文件和基准标记工具以及在分布式异构环境中建立“执行契约”来说是关键的3J-RAF2在我们的CPU核算方案中，Java类的字节码被重写，以使其CPU消耗显式。每个线程计算自己的CPU消耗，表示为执行的JVM字节码指令的数量。每个线程定期将收集到的有关其自身CPU消耗的信息汇总到一个帐户中，该帐户可能与许多其他线程共享。我们称这种方法为自我核算。在这些信息更新例程期间，线程还将执行管理代码，例如，以确保不超过给定的资源配额。以这种方式，J-RAF 2的CPU管理方案不依赖于专用的管理程序线程，因为管理活动分布在系统中的所有线程之间，从而有效地实现了一种形式的自我控制。因此，这对我们来说是可移植性和可靠性的保证，我们不依赖于JVM提供的底层调度，这在Java语言[15]和JVM [19]规范中有松散的规定：虽然有些JVM似乎提供了抢占式调度，以确保具有高优先级的线程将在准备运行时执行，但其他JVM根本不考虑线程优先级。这与我们以前的计费方案[5]有很大的不同，以前的计费方案依赖于线程优先级进行调度。相比之下，J-RAF 2允许用户编写平台无关的CPU管理代码（如自定义编译器），它可以在所有类型的Java平台上工作。在下面的小节中，我们总结了我们的便携式CPU计费方案。J-RAF 2运行时类的低级实现细节在其他地方介绍[16]，编程API和程序62W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）57public final class ThreadCPUAccount {public static String getString（）;public void consume（）;public void setManager（）;...}从中间件开发人员的角度来看[4]。与这些以前的出版物相比，本文侧重于我们的CPU管理方案的好处和普遍适用性。3.1将会计信息与线程关于字节码转换（或重写）方案，我们的两个主要设计目标是确保可移植性（通过严格遵守Java语言和虚拟机的规范）和性能（通过最小化由于插入到原始类中的额外指令而产生的开销）。每个线程都有一个关联的ThreadCPUAccount。图1总结了公共接口的一部分。方法和字段的语义将在本小节和以下小节中解释。线程与其ThreadCPUAccount的关联在线程的整个生命周期内持续存在。当一个新的线程对象被初始化时，它会自动接收一个新的ThreadCPUAccount对 象 [16] 。 getCurrentAccount （ ） 方 法 返 回 调 用 线 程 的ThreadCPUAccountFig. 1. ThreadCPUAccountAPI的一部分。3.2字节码转换方案在正常执行期间，每个线程更新其ThreadCPUAccount的消耗计数器。为了调度共享管理任务的定期激活，计数器根据可调整的限制（计数粒度）进行检查[16]。更准确地说，当本地消费计数器超过由记账粒度定义 的 特 定 限 制 时 ， 每 个 线 程 都 会 调 用 其 ThreadCPUAccount 的consume（）为了优化消耗计数器是否超过此限制的比较，计数器从粒度值乘以-1到零运行，当它等于或超过零时，调用consume（）方法。在JVM字节码中，有专门的指令用于与零进行比较. 为了应用这种CPU核算方案，（非原生和非抽象）方法以以下方式重写：W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）5763(i)在每个方法的开头，当前线程必须使用静态方法getCurrentAccount（）获取。(ii) 插入条件是为了定期调用consume（）方法。一般的想法是尽量减少检查是否必须调用consume（）的数量，但仍然要确保恶意代码在不调用consume（）的情况下无法执行无限数量的字节码指令。条件在条件中，变量cpu引用当前执行线程的ThreadCPUAccount(iii) 最后，更新消耗计数器的指令插入到每个记帐块的开头。 记帐块与基本代码块的概念相关，不同之处在于方法和构造函数调用可以发生在记帐块内的任何位置。有关会计区块定义的详细信息可以在其他地方找到[5]。为了减少记帐开销，前面插入的条件不被视为单独的记帐块。3.3重写示例图2说明了如何使用我们的CPU核算方案转换方法。在这个例子中，我们没有显示消费变量递增的具体值;这些值由重写工具静态地计算，并且表示将在下一个计费块中执行的字节码的数目。2根据不同的应用，每个计费块的具体值可以用不同的方式计算• 在重写发生之前，记帐块中的字节码指令数。也就是说，所产生的CPU消耗反映了原始的、未修改的程序将执行的字节码指令的数量。此设置对于分析和基准测试特别有用• 重写后记帐块中的字节码指令数，包括插入的记帐指令。也就是说，所产生的CPU消耗包括记帐开销。特别是，此设置允许服务提供商向客户端收取总CPU成本，2为了更好的可读性，我们在Java代码上显示转换，而我们的实现工作在JVM字节码级别。64W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）57部署的客户端组件的消耗。• 对于前两个设置中的每一个，每个JVM字节码指令可以接收不同的权重，因为JVM字节码指令的不同类别的复杂度这允许校准特定JVM的会计，从而更好地建模特定JVM上的有效CPU负载。public intfindDuplicate（intfindDuplicate）{public int findDuplicate（int findDuplicate）{ThreadCPUAccount cpu;System. out. println（）;CPU.consumption +=...;if（cup.consumption）;public void run（）;-->public void run（）;while（x > 0）{while（x > 0）{CPU.consumption +=...;if（cup.consumption）;int x（x）;int x（x）;}}}}图二. 重写之前和之后的示例方法3.4聚合CPU消耗通常，每个ThreadCPUAccount对象都引用CPUManager的实现，该实现在属于某个组件的所有线程之间共享。3CPUManager实现由中间件开发人员提供，并实现实际的CPU计费和控制策略，例如，自定义调度方案。J-RAF 2提供了一种继承机制，该机制保证派生线程最初受到与其创建者线程相同的CPU管理方案，即，派生线程ThreadCPUAccount的setManager（CPUManager）方法允许程序员显式更改CPU管理器实例。CPUManager接口包含consume（long）方法。当线程在其ThreadCPUAccount上调用consume（）时，此方法将通过调用consume（long）将其收集的CPU消耗数据（存储在consumption字段中）报告给与ThreadCPUAccount关联的CPUManager。consume（long）方法实现了自定义的CPU计费和控制策略。它可以简单地聚合3这里的“组件”一词根据设置，组件可以转换为例如可重用线程池，或者转换为具体的保护域，如隔离[18]。W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）5765public class SimpleCPUManager实现CPUManager {protected longconsumption = 0;public void consume（long c）{consumption += c;} publicsynchronized long getConsumption（）{return consumption;}}报告的CPU消耗（并将其写入日志文件或数据库），它可以强制执行绝对限制并终止超过其CPU限制的组件，或者它可以限制组件的线程的执行速率（即，如果超过给定的执行速率，则将线程暂时置于睡眠状态）。这是可能的，而不会破坏安全性假设，因为消费（长）调用是同步的（即，阻塞），并由策略所应用的线程直接执行。作为一个例子，一个简单的CPUManager实现如图所示。3 .第三章。consume（long）方法是同步的，因为多个线程可以并发调用它SimpleCPUManager实现维护所有报告的消耗信息的总和，它不强制执行任何CPU限制。图三. CPUManager实现：不受控制的CPU计费。3.5性能性能评估显示，基于字节码指令计数的CPU管理在最近的JVM上造成了17-30% 的开销。我们在 Linux RedHat 9计算机（Intel Pentium 4 ，2.6GHz，512 MB RAM）上运行SPEC JVM98基准测试套件[27]。JVM98类以及所有JDK类都被重写用于资源管理。整个JVM98基准（由多个子测试组成）运行10次，通过计算每个子测试中位数的几何平均值获得最终结果。最有希望的结果是使用IBM的JDK 1.4.2平台获得的，其中开销可以保持在低至17%。使用Sun的JDK 1.5.0，HotSpot客户端VM的开销约为25%，HotSpot服务器VM的开销约为30%。有趣的是，在绝对时间上，在IBM的JVM上，有会计的基准执行速度比没有会计的Sun的HotSpotClient VM快20%，与没有会计的Sun的HotSpot Server VM一样快。这表明，使用J-RAF 2的可移植CPU管理机制增强的标准JVM（在本例中为IBM66W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）574案例研究在本节中，我们将讨论最近的五个案例研究，其中我们应用J-RAF 2来评估和比较算法的性能，增强现有的具有CPU管理功能的中间件，并提高计算网格中的安全性和负载平衡，以及普适计算场景中的软件4.1基准测试和分析正如第1节所讨论的，Java应用程序的基准测试和性能分析是一项复杂而耗时的任务。一方面，现有的Java profilers导致了巨大的速度减慢，通常是精确profiling的10倍。因此，它们不适合评估复杂的应用程序。另一方面，基于经过的挂钟时间的算法的简单基准测试需要准备良好且隔离的基准测试机器（没有后台进程）、多次运行以及数据的统计处理，因为通常测量结果由于测量粒度以及即时编译和垃圾收集的动态性而不能精确地再现。我们在使用J-RAF 2进行性能评估方面取得了很好的经验。由于J-RAF2引入了抽象的测量单元，结果是完全可重复的，尽管基准测试可以作为开发人员机器上的后台进程运行。会计总是准确的，不需要为了减少由于测量粒度而导致的不精确性而放大输入数据。我们现在使用J-RAF 2在各种服务组合算法的评估中[10]。使用J-RAF 2进行性能评估已经带来了生产率的提高，因为我们不必维护专用的基准测试环境。图4说明了我们的基准测试解决方案的简单性。 我们假设基准测试的主类实现了Runnable接口，并且其类名作为命令行参数传递。所示程序动态加载并重写基准的类文件。首先，JRAF 2ClassLoader动态地将J-RAF 2字节码重写工具应用于加载的类。然后程序创建一个新的CPUManager实例，并将其与当前线程的ThreadCPUAccount对象相关联（即，原始应用程序线程）。调用ThreadCPUAccount的consume（）方法可确保将ThreadCPUAccount为了计算基准测试程序执行的字节码指令数，我们只需比较CPUW. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）5767公共静态void main（String[] args）抛出异常{ClassLoader cl = new JRAF 2ClassLoader（）; //动态重写加载的类Class c = cl.loadClass（args[0]，true）; //加载、重写和链接所需的类Runnable benchmark =（Runnable）c.newInstance（）; //实例化重写的类SimpleCPUManager manager = new SimpleCPUManager（）;ThreadCPUAccount cpu = ThreadCPUAccount.getCurrentAccount（）; cpu.setManager（manager）;CPU.consume（）;// flush ThreadCPU Account consumption counter longconsumptionBefore = manager.getConsumption（）;benchmark.run）;CPU.consume（）;// flush ThreadCPU Account consumption counter longconsumptionAfter = manager.getConsumption（）; System.out.println（“基准执行的字节码指令：“+（consumptionAfter -consumptionBefore））;在基准执行之前和之后的消耗。CPUManager继承机制确保由基准产生的线程将向同一个CPUManager对象报告它们的CPU消耗。见图4。 使用J-RAF 2对应用程序进行基准测试。如果基准测试类使用JDK的功能（通常是这种情况），则还必须重写JDK以进行资源管理。虽然在这个例子中，基准测试类是由一个特殊的J-RAF 2类加载器动态重写的，但是在运行基准测试之前，JDK类总是必须被重写这在J-RAF 2安装期间发生一次，它创建了以前安装的JDK的资源感知版本。许多最近的JVM都支持如果JVM不支持此选项，则必须用重写版本替换核心类（例如，这可能是J2ME设置中的情况通过为程序执行的不同部分使用不同的CPUManager实例，可以区分CPU消耗（配置）。然而，由于这种方法对于细粒度的profiling并不实用，我们正在开发另一种工具，Java Profiler JP。JP基于与J-RAF 2类似的字节码重写技术，但它为每种方法维护单独的信息：完整的调用堆栈（调用上下文）、方法调用计数器和所有方法调用所执行的字节码指令数。我们已经获得了SPEC JVM 98基准的详细执行统计数据[27]，比我们发现的任何其他精确的Java profiler都要快得多（平均而言，JP会导致2-3倍的开销68W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）574.2应用服务器除了普遍存在的安全性和可靠性问题外，电子商务基础设施（如应用程序服务器）还需要具有高可用性和盈利能力。为了研究在这样的环境中支持计费策略的资源会计，我们将我们的框架应用于ApacheTomcat servlet引擎4。我们能够精确地监控每个请求的CPU和网络带宽消耗，并将这些数据实时报告给数据库服务器。主要的挑战是，首先，能够为所收集的非结构化、低级别的会计信息分配语义的、真实的含义，其次，要处理Tomcat使用线程池来执行http请求的事实由于servlet可以自由地产生工作线程，而Tomcat引擎不会注意到这一点，从而导致必须正确报告的额外资源消耗，这使得情况更加复杂。我们强加给自己的约束是将servlet代码视为遗留（即，源代码并不总是可供修改）。另一方面，我们允许自己利用Tomcat作为一个开源项目来提取http请求和详细说明相应回复的主线程的身份之间的语义关联。利用上一节中提到的管理器继承机制，我们让每个工作线程继承其各自主请求线程的专用CPUManager这种组合允许集成工作线程的消费，因此我们实现了对上述挑战的相当完整和直接的解决方案。4.3可扩展目录在我们以前的工作[3，8，9]中，已经提出了（语义）Web服务的目录它提供了特定的功能，以实现Web服务的有效组合，将输入和输出消息的类型约束纳入考虑[10]。服务组合算法访问目录检索Web服务的描述，这些Web服务可以被组合以满足给定的要求，定义为一组所需的输出消息。由于特定服务组合问题的相关服务数量可能非常大，因此目录允许增量检索结果。服务组合算法的性能在很大程度上取决于目录返回（部分）匹配结果的由于对服务组合的研究还处于起步阶段，需要大量的实验来开发工业强度的算法，第http://jakarta.apache.org/tomcat/W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）5769应该灵活地支持不同的排序算法，对于不同的服务组合算法，不同的排序算法可能更有效。该目录后来被扩展为支持用户定义的修剪和排名功能，这使得直接在目录中动态安装应用程序特定的工具。也就是说，新版本的目录是可扩展的。 自定义修剪和排名函数是用Java编写的，原因如下：Java对许多程序员来说是众所周知的，有很多Java编程工具，最重要的是，它与完全用Java编写的目录集成得将用户定义的代码集成到目录中利用了最近JVM实现中最先进的优化。例如，HotSpot VM [23]首先解释JVM字节码并收集执行统计数据。如果代码执行得足够频繁，则会将其编译为优化的本机代码以实现快速执行。通过这种方式，频繁使用的修剪和排名功能可以像直接内置到目录中的算法一样高效地执行为了保护目录免受错误或恶意客户端代码的攻击，它对用户定义的修剪和排名函数施加了严格的限制。例如，客户端代码可能只使用非常有限的API，不允许在堆上分配内存，不能使用同步原语，也不能定义异常处理程序。在JavaSeal [28]和J-SEAL 2 [2，5]移动对象内核中研究了有效的扩展字节码验证，以强制限制JVM字节码，从而安全执行不受信任的上述限制在加载时强制执行，部分在运行时强制执行，并确保用户定义的代码不会干扰目录的内部结构，从而导致不必要的副作用。为了防止拒绝服务攻击，可扩展目录的早期版本甚至要求客户端代码是非循环的，即，不允许循环最近，我们使用J-RAF 2来克服这一限制，并为CPU控制重写了自定义修剪和排名函数。这些函数现在可以使用循环构造，因为它们的CPU消耗受到目录提供者定义的CPU控制策略的限制。查询的执行需要重复调用客户端代码。在调用用户定义的函数之前，线程附加到一个CPUManager，该CPUManager对每个查询的CPU消耗实施严格的绝对限制。 CPU限制表示为在整个查询处理过程中允许由用户定义代码执行的字节码指令的数量。如果超过了这个限制，consume（long）方法抛出一个异常，这将中止用户代码的执行（记住，自定义函数不允许定义异常处理程序）。然后，目录将捕获异常并终止整个查询。70W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）57在这种设置下，CPU记帐的运行时开销可以忽略不计，因为只有不受信任的用户定义的代码才被重写用于CPU记帐。目录本身不会被重写，其执行也不会被考虑。由于服务组合客户端可能会对多个查询使用同一组修剪和因此，减轻了动态字节码重写的开销4.4计算网格在其他以前的工作[17]中，我们描述了一个计算网格模型，该模型依赖于在安全的基于Java的内核中运行的移动代理。该模型的目标是从经济和技术的角度提出一个现实的部署方案，因为我们描述了一个设置，其中计算资源的提供商（个人或企业）可以根据其服务按比例获得奖励，并且依赖于实际工具和环境广泛解决性能和安全性等问题。使用执行的字节码指令的数量作为度量有助于解决两个更具体到网格设置的重要问题。首先，很难在极端异构的环境中分配计算负载。为了解决这个问题，所有计算资源的提供者都向网格运营商提供最新的负载信息，这些信息表示为最近执行的Java字节码的数量。将该数据与资源提供者各自的负载能力和声明的偏好进行比较，以调整新计算任务的分布。在这种情况下必须解决的第二个问题是，资源提供者可能会收到（可能是经济上的）奖励，这是为了防止作弊。我们提出的网格业务模型依赖于一方面，客户端支付网格运营商的分布式执行他们的应用程序，另一方面，运营商支付的资源提供商为他们闲置的计算资源。客户端从操作员购买执行票（特殊令牌），部署代理将其传递给资源提供者以获得其服务。后者在运营商处赎回接收到的执行票据。执行票类似于一种加密保护的货币，只在网格内有效。如果一个资源提供者没有提供所需的服务，网格运营商将很快注意到这一点。如果结果是一个资源提供者在没有提供适当服务的情况下收集了票，那么运营商最终可能会决定将他从网格中删除。通过将请求的票证数量与实际执行的工作相关联，可以检测到此类恶意行为者，W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）5771专用执行环境内的CPU监控。4.5普适计算在欧盟项目PalCom5中，我们探讨了以下场景：在普适计算领域，一个普遍预期的特征是软件从一个设备传播到另一个设备的能力与上面提到的网格示例一样，这是一个高度异构的设置。因此，有必要以便携的方式表达每个设备的计算能力，因为用沉重的组件使几乎不保密的设备过载的风险。反之，目标设备将想要提前知道所提出的软件组件是否具有超出本地可能性的静态或动态需求。为了解决这个问题，我们建议为每个组件（例如，Java jar文件）与描述其静态（即，加载时间和激活）资源要求。此外，组件的动态需求和环境的策略应根据绝对和基于速率的CPU消耗（使用字节码指令计数作为度量）来表示，以保证资源感知行为的可移植性。如果更强，例如，为了保证软件组件的正确执行是实时的，建议将其描述为在线的，以便以可移植的度量单位获得所有所需资源的上限。组件会将这些值声明为它的加载时要求，然后只由符合这些要求的目标设备加载虽然前面的网格计算场景是相当静态和集中的（操作员提前知道组件是否适合给定的目标主机），但这个普适计算示例是尽可能分散的，因为每个设备和每个组件都必须能够确定它们是否兼容。5相关工作通过字节码转换改变Java语义已经被用于许多目的，这些目的通常可以被描述为向现成的软件组件添加反射或面向方面[26]。我们的方法也适合这种描述，因为我们实际上具体化了CPU消耗，这是一个原始的想法。尽管已经为工程字节码开发了许多工具，但J-RAF 2依赖于现有的BCEL [14]进行低级操作。http://www.palcom.dk/72W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）57在基于Java的平台中提供资源控制的流行方法依赖于修改的JVM、本机代码库或程序转换。例如，Aroma VM [25]、Ka eOS [1]和MVM [11]都是支持资源控制的专用JVM。JRes [13]是Java的资源控制库，它使用本地代码进行CPU控制，并重写Java程序的字节码进行内存控制。对于CPU控制，还应用了一些轻量级字节码重写，以便通过本机代码库与操作系统进行适当的协作。没有进行字节码级的会计，因为这似乎在性能方面令人望而却步。另一个不同之处是，在JR中，信息是通过轮询OS来获得的，这些信息是关于线程的CPU消耗的，因此需要一个具有OS级线程的JVM，而这并不总是可用的。最近，Sun的研究人员发表了一份报告，介绍了他们将资源管理作为Java语言不可分割的一部分的方法[12]。他们已经接受了一个非常广泛的调查领域，因为他们的野心是，例如，考虑物理和逻辑资源（如端口或文件描述符），并通过多方决策和通知为复杂的人工策略提供直接支持（而J-RAF 2专注于较低级别的设施，同时将大量灵活性留给应用程序和中间件开发人员）。他们的提议中值得注意的一个方面是，它需要事先部署Java隔离物[18]。随着Java平台的相继发布，Sun已经提供了几个其他的管理和运行时监控API，特别是针对堆内存，但是目前没有解决方案可以广泛地应用于各种环境，也没有一个解决方案可以作为实现控制策略（与监控相反）的基础，或者像本框架一样与语言集成。以前关于J-RAF的工作[5]已经表明，其他基本资源，如堆内存和网络带宽，可以在一个单一的同构概念和技术框架中进行说明。需要进行更多的研究，以将这些资源的会计处理提升到与此处介绍的CPU管理框架相同的成熟度水平。一种用于组层次结构中的资源管理的正式模型（例如，Moreau和Queinnec [20]提出了一种新的方法。在此模型中，父组为其子组提供资源。当子节点耗尽资源时，通知机制通知父节点。作者还描述了一个Java原型，但他们没有提到对CPU管理的任何支持。J-SEAL 2内核[5]也使用了类似的分层资源管理模型，它也支持CPU管理，但基于一个比W. Binder，J.Hulaas/Electronic Notes in Theoretical Computer Science 153（2006）5773本文提出Real-Time for Java Experts Group [7]已经发布了一项向Java添加实时扩展的提案。这项工作的一个重要重点是确保可预测的垃圾收集特性，以满足实时保证。另一个实时系统，PERC [21]，扩展了Java以支持实时性能保证。为此，PERC系统分析Java字节码以确定内存需求和最大执行时间，并将该信息馈送到实时调度器。实时系统的目标是提供精确的保证，例如，最差执行时间相比之下，我们的重点是在一个独立于硬件的测量单元，这是足够的监控和防止拒绝服务攻击的计算资源消耗。6讨论在本节中，我们将讨论CPU管理框架的优势和局限性。首先，也是最重要的，我们的CPU管理方案是完全可移植的。J-RAF2是用纯Java实现的，所有的转换都严格遵循Java语言和虚拟机的规范。它已经在不同环境中的几个标准JVM上成功测试过，包括Java 2 MicroEdition [6]。我们的方法的一个新颖之处是使用一个便携式的，独立于硬件的CPU消耗测量单位。在我们的方法中，修改后的