移动Agent安全：Java中的资源控制模型及实现机制

1理论计算机科学电子笔记63（2001）网址：http://www.elsevier.nl/locate/entcs/volume63.html16页Java中的可移植资源控制：在移动Agent安全W alter Bindera，1，Jarle G. Hulaasb和AlexVillaz'onb，2aCoCo软件工程，列支敦士登。22/9，1040 Vienna，Austria电子邮件：w. coco.co.atb日内瓦大学，rueG′en′eralDufour24，1211Geneva4，Switzerland电子邮件：Jarle. cui.unige.ch摘要防止拒绝服务攻击是分布式代理系统安全运行的必要条件。为了实现所需的防御机制，必须支持资源控制，即，计算和限制CPU、内存和线程等资源的消耗。Java是移动代理系统的主要实现语言，即使资源控制是标准Java平台上缺少的功能。此外，Java中流行的资源控制方法需要本地代码库的大量支持，这对于可移植性来说是一个严重的缺点，因为它阻止了在大规模异构网络上部署应用程序。本文描述了J-SEAL 2移动代理内核的新资源感知版本的模型和实现机制 资源控制模型基于一组需求，其中可移植性非常重要，以及与现有编程模型的自然集成。该实现包括Java字节码重写与J-SEAL 2内核中精心选择的增强功能的组合。资源控制系统的实现可以由诸如需要应用服务提供商来保证一定的服务质量或创建对基于使用的计费的支持的动机来促进。然而，在本文中，设计策略侧重于安全性，更具体地说，是防止来自平台上运行的移动代理的拒绝服务攻击。初步的性能测量，这支持我们的方法。1介绍Java [15]被设计为一种通用编程语言，特别强调可移植性，以增强对分布式1 由CoCo Software Engineering GmbH提供支持。2由瑞士国家科学基金会资助2001年由ElsevierScienceB出版。 诉 操作访问根据C CB Y-NC-N D许可证进行。BINDER，HULAASANDVillaZO'N2应用.因此，从一开始就没有纳入对低级、高度依赖机器的机制的然而，正在构思新的应用程序类别，这些应用程序依赖于Java提供的设施这些新的应用程序基于代码移动性带来的可能性，打开了传统的环境，在机器之间任意移动，并发执行，并在设备上竞争资源，这些设备可以找到从适度到丰富的配置。因此，我们目睹了对公平性和安全性的日益增长的需求，更好地理解和掌握资源管理等低层次问题变得必不可少。操作系统内核提供了强制进程资源限制的机制。调度程序根据进程优先级将进程分配给CPU。此外，只有内核可以访问所有内存资源。进程必须从内核分配内存区域，内核验证进程的内存限制没有被超过。 同样，移动代理内核必须防止拒绝服务攻击，例如代理分配所有可用内存。为此目的，会计的物理资源（即，内存、CPU、网络带宽等） 以及逻辑资源（即， 线程数、保护域数等）是至关重要的.尽管J-SEAL 2 [5，6]主要是为移动代理设计的，但这里描述的方法在许多方面都适用于Java中实践的其他分布式编程范例，因为移动代理范例在涉及的问题和技术方面非常全面。因此，J-SEAL 2中采用的技术可以大大提高Java Applet、Servlet、Enterprise JavaBean或传统分布式应用程序执行的稳定性和安全性，这些应用程序通常需要强大的保护域和资源控制机制。资源控制的巨大价值在于它不限于作为实现安全机制的基础。应用服务提供商可以例如，需要保证一定的服务质量，或者创建对基于使用的计费的支持，以便分期偿还在客户处置的这里描述的基本内核扩展然而，本文仅限于为J-SEAL 2添加资源控制所必需的内核扩展;忠实于微内核方法，J-SEAL 2将不必绝对成为内核一部分本文的结构如下。下一节将介绍设计目标和最终的资源控制模型。第3节概述了我们的实现技术，第4节介绍了初始性能测量。第5节与相关工作进行了比较，而第6节则对未来的研究进行了展望，并对文章进行了总结BINDER，HULAASANDVillaZO'N32目标和结果模型这项工作的最终目标是创建一个执行平台，在这个平台上，匿名代理或更通用的程序可以安全地共存，而不会相互伤害，也不会损害它们的环境。这种平台的例子是用户可扩展数据库[14]或分散式电子商务和交易系统，例如[16]。部署这种平台的愿望转化为以下要求：• 非常抽象的概念，以使策略到实现的映射更加简单，并使资源控制和最终的计费更加易于管理。• 对低级物理资源以及高级逻辑资源（如线程）的记帐。• 防止基于CPU、存储器或通信滥用的拒绝服务攻击• 在并发域之间公平分配资源，即使在恶意活动的环境之外。• 机器集群上移动代理应用程序的细粒度负载平衡。由于资源控制的某些方面是由应用程序开发人员管理的，因此通用模型与现有的J-SEAL 2编程模型很好地集成是很重要的[5]。J-SEAL 2内核管理嵌套的保护域3的树层次结构，即所谓的密封。这种分层组织的保护域模型源于JavaSeal移动代理内核[9]。保护域封装移动代理以及服务组件4.J-SEAL 2内核确保保护域彼此完全隔离，不同域之间没有直接共享。此外，父域可以终止其子域迫使孩子们立即释放所有分配的资源资源控制设施应符合分级系统结构。分层进程模型已经被操作系统内核成功地使用，例如Fluke微内核[12]。Fluke内核采用分层调度协议，CPU继承调度[13]，以执行调度策略。在这个模型中，父域将其自己CPU资源的一定百分比捐赠给子进程。最初，层次结构拥有所有CPU资源。分层资源控制的一般模型，如Quantum [18]，非常适合J-SEAL 2分层域模型。 在系统启动时，3在本文中，术语“保护域”是指操作系统中的进程或任务的概念，而不是指JDK类java.security.ProtectionDomain。4 在J-SEAL 2中，不允许移动代理直接使用JDK，例如文件或网络IO，但它们必须访问在单独的保护域中执行BINDER，HULAASANDVillaZO'N4完全受信任的域（无需记帐）图1.一、一般资源控制模型的说明根域RootSeal默认拥有所有资源，例如100%的CPU，整个虚拟内存，无限的网络使用，底层Java虚拟机（JVM）[17]能够处理的最大线程数，无限数量的子域等。然而，如果特定配置甚至需要对受信任域进行核算，则当创建嵌套保护域时，创建者将其自己的部分资源捐赠给新域。图1说明了在密封层次结构中共享或分布资源的方式。在J-SEAL 2的正式模型中，Seal演算[25]，父seal监督其所有子域，域间通信管理是目前主要关注的问题。同样，在这里提出的资源控制模型中，父印章负责与其子印章的资源分配。这就产生了一个嵌套结构，其中父seal最初是其资源的唯一所有者，它可以共享这些资源，也可以分派其中的一部分资源到它的子封印。然而，保护域内的所有资源的总和，例如，在图1的不可信应用程序中，保持不变。我们的资源控制模型源于进一步的设计目标，例如可移植性和透明性：下面的小节将专门描述这些。2.1可移植性和透明度可移植性是任何移动代理平台成功的关键。那里 已经有一些基于Java的系统来运行资源控制设施，例如Alta [24]，GVM [4]，Ka eOS [1，2]等。因此，这些系统不适合于必须支持各种各样的应用的大规模应用。RootSealCPUMEM非受信应用CPU5%内存40 MBCPU15%内存10 MB88BINDER，HULAASANDVillaZO'N5不同的硬件平台和操作系统。 我们的目标是提供一个通用的模型，不依赖于特定的实现技术，并主要探索完全可移植的解决方案。这意味着我们必须应对某些限制，并且性能水平有时低于现有的实现。我们的便携式ap-proach仍然将显示其优势，从长远来看：我们的解决方案将始终执行速度比最快的JVM没有资源控制机制，但在另一方面，我们将能够利用最新的技术在Java实现优化，这往往是不可能的非便携式实现。2.2受信任域由于J-SEAL 2是为大规模应用程序设计的，其中大量的服务和代理并发执行，设计和实现必须最大限度地减少资源核算的开销。 一些领域，如作为核心服务，完全值得信赖。它们的资源消耗不需要由内核控制。2.3支持资源共享在某些情况下，作为层次结构中的邻居的保护域可以选择共享一些资源。在这种情况下，将对一组保护域一起实施资源限制。因此，资源碎片化被最小化。例如，考虑一个代理为某个任务创建子代理。通常，创建代理不希望将某些资源捐赠给子代理，而是更愿意与子代理共享自己的资源。我们的方法的一个属性是，如果一个域对一个资源具有无限的访问权限，这意味着它与RootSeal共享它2.4托管资源在每个不可信保护域中，J-SEAL 2内核应考虑以下资源（有关详细信息，请参见[7]）：• CPU RELATIVE定义CPU的相对份额，并表示为父域自身相对份额的一部分。在我们当前的实现中，此资源由执行的字节码指令量的周期性采样控制。此外，测量的精度取决于实施方式5。• MEM ACTIVE是保护域在任何给定时刻允许使用5存在偏差，因为在实施中，参考值是聚合的置信度，在不受信任的域中测量消耗，而不是如预期的那样，将资源作为一个整体。BINDER，HULAASANDVillaZO'N6• THREADS ACTIVE指定任何时候保护域的最大活动线程数。必须避免不受控制地创建线程，因为这会增加调度程序的负载，甚至可能使JVM崩溃。• THREADS TOTAL限制了在保护域的整个生命周期中可以创建的线程数量，因为线程创建是一个开销很大的（内核级）操作。• DOMAINS ACTIVE指定在任何给定时刻允许保护域拥有的活动子域的最大数量。这个限制的存在是为了通过随时控制密封层次结构的复杂性来• DOMAINS TOTAL限制了保护域在其整个生命周期中可能生成的子域的数量，因为域创建和终止是昂贵的内核操作。请注意，J-SEAL 2的内核不负责网络控制。这是因为微内核不提供对网络的访问。相反，网络接入可以由多个服务提供。这些网络服务或层次结构中的某些中介层负责根据特定于应用程序的安全策略进行网络计费。让我们强调，网络并不是一个特例，因为J-SEAL 2由于其同质模型，可能会限制与任何服务的通信，如联网、文件IO等。带宽限制）以及服务访问的撤销由通信模型处理，本文不涉及该在上面的内核管理的资源列表中，可以预期的另一种资源是在给定保护域的整个生命周期中分配给它的CPU总量。然而，尚不清楚该资源的测量单位应该是什么，同时仍然保留完全独立于硬件的模型。由于这种资源核算的主要目标是防止应用程序无限地扰乱平台，因此在异构的服务器集合中，将总生命周期抽象地表示为应用程序启动后经过的挂钟时间比表示为消耗的CPU周期数更有使用执行的Java字节码的数量，虽然可移植，也被认为是太低级了。测量挂钟时间可以在应用程序级别实现，通过建立具有足够权限的控制器代理来杀死所有行为不端的应用程序。在J-SEAL 2中，当父封装处理子封装时，所有的资源都被保证被正确释放，因此总CPU时间的计算从内核中被丢弃。最后，也不存在MEM TOTAL这样的资源，MEM TOTAL是对保护域整个生命周期中使用的累积内存量的限制。可能需要它来防止恶意代理创建大量动态对象以保持BINDER，HULAASANDVillaZO'N7CPU忙于垃圾收集，但它的实现需要维护一个额外的计数器，这是我们希望避免的。相反，J-SEAL 2将采取预防措施，通过收取抽象数量的CPU作为对每个创建的对象引起的垃圾收集的补偿3执行在这一节中，我们将简要介绍为实现前一节中讨论的资源控制模型的完全可移植性而采用的技术。具体的实现可以参见[7]。由于对逻辑资源（如线程和子域）的核算只需要对一些J-SEAL 2内核原语进行简单的修改，因此我们将重点放在对物理资源（如内存和CPU）的核算上。3.1无直接共享自J-SEAL 2内核最初发布以来，它就被设计为简化资源控制工具的集成。它保证问责制，即，每个对象属于恰好一个保护域。对对象的引用仅存在于单个域中，即，在J-SEAL 2中，在不同的域之间不存在对象引用的直接共享。因此，可以将每个分配的对象精确地计入一个保护域。此功能不仅简化了资源核算，而且对于在域终止期间立即回收资源也至关重要。3.2字节码重写在我们的方法中，我们采用字节码重写技术的内存和CPU会计。这是因为据我们所知，这是实现所需核算机制的唯一完全可移植的方式。它期望每个应用程序的源代码都可供修改是不现实的。此外，如果我们想要保证不受拒绝服务攻击，我们就不能依赖外来代码来执行任何自愿的自限制操作，而如果我们在它开始执行之前修改它的字节码，我们就可以在我们的实现中，Java类的字节码在被JVM加载和链接之前被修改（关于类加载的细节，请参见[17]）。在每个内存分配指令之前插入内存核算代码。CPU记帐使用一个抽象的度量，即执行的字节码指令数。因此，CPU记帐的代码包含在每个基本代码块中。 在重写之前，对于CPU核算，因为内存核算插入额外的字节码指令来强制执行内存限制，而CPU消耗的核算不涉及任何对象分配。BINDER，HULAASANDVillaZO'N8在我们的实现中，在需要内存或CPU控制的域中执行的线程具有表示资源限制和当前消耗的关联会计对象。由于对记帐对象的访问可能非常频繁，我们正在重写非本机方法，以便将必要的记帐对象作为附加参数传递。本机方法被排除在重写之外，因为我们无法考虑本机代码分配的内存和消耗的CPU时间。我们依靠最先进的JVM实现的现代模块间寄存器分配算法来最小化传递记帐对象的开销3.3类加载J-SEAL 2内核区分了共享类和复制类[6]。共享类由系统类加载器加载（它们在JVM中只存在一次），而复制类（如移动代理的类）由保护域的类加载器加载（它们在每个域）。所有JDK类6以及J-SEAL 2内核中的大多数类都是共享的。 某些经常使用的J-SEAL 2库类可能也可以共享，以避免多次重新加载的开销。由于一个共享类可以被完全信任的域（不需要计算）以及不信任的域（需要资源控制）引用，因此它必须提供每个方法的多个不同版本。没有资源控制的版本对应于未修改的代码，而不受信任的域使用的版本将会计对象作为额外的参数，并包括必要的会计指令。共享类被重写为单行（例如，在J-SEAL 2平台的安装过程中），因为我们不能以可移植的方式修改系统类加载器，它是Java运行时系统的一部分。复制的类在被链接到JVM之前立即被在线重写。因此，一个移动代理可以在它被信任的J-SEAL 2平台上执行未修改的代码，而在另一个J-SEAL 2安装上，同一代理的代码可以被重写以进行资源控制。3.4存储器控制像在JRes [10]中一样，在每个内存分配指令之前插入内存控制代码。J-SEAL 2内核维护对分配对象的弱引用，以便检测对象何时被回收。强制执行内存限制需要对内存资源进行精确的预先核算，即，过度使用异常在线程可以超过其正在其中执行的域的存储器限制之前被引发。与JRes不同，JRes为每个线程控制单独的内存限制，J-SEAL 2能够强制使用单个内存6不可能使用与系统类加载器不同的加载器加载JDK类BINDER，HULAASANDVillaZO'N9对于多线程域，或者在资源共享的情况下，甚至对于一组域，都有限制。3.5CPU控制CPU计数是基于一个抽象的度量，即执行的字节码指令的数量基本上，CPU计费的指令被插入在每个基本代码块的开头7。为了防止对公共CPU帐户对象的竞争，在不受信任的域中执行的每个线程都维护其自己的CPU帐户。高优先级计划程序线程定期执行，以确保遵守分配的CPU限制。中执行的所有线程的记帐数据一个域。调度器线程将执行的字节码的数量与所需的调度进行比较，并调整各个线程的JVM线程优先级。双线程，以控制CPU的消耗不同的保护域8.3.6垃圾收集为了通过使垃圾收集器消耗大量的CPU时间（例如，攻击者可能在不超过其内存限制的情况下创建大量垃圾），J-SEAL 2内核必须考虑垃圾收集器所花费的时间。由于垃圾收集器花费的确切CPU时间是未知的，因此我们使用一个抽象的度量。J-SEAL 2管理员定义了回收对象所需的字节码指令在分配对象之前，J-SEAL 2内核会对分配线程的CPU也就是说，域必须为它在“购买”对象时最终产生的垃圾“付费”。这种简单的方法有一个优点，一个域是收费的所有垃圾，它产生的，甚至当某些对象被回收时，如果域已经终止3.7避免使用本机代码在字节码重写技术的帮助下，不可能在本机代码中考虑内存分配和CPU消耗。不受信任的应用程序不允许将本机代码库带入系统。关于JVM提供的标准操作，J-SEAL 2内核试图补偿本机代码使用的资源，并防止不受信任的域使用某些功能，从而导致本机代码消耗大量资源。7在[7]中，我们提出了一些简单的优化规则，允许结合会计代码，一组基本积木。8在J-SEAL 2中，不允许在不受信任的域中运行的线程修改自己的优先级。我们正在使用扩展字节码验证来确保此属性（有关详细信息，请参阅[6]）。BINDER，HULAASANDVillaZO'N10代码. 在下文中，我们描述了本机代码中资源消耗的一些重要情况以及J-SEAL 2如何解决它们：• 类加载：Java运行时系统管理一个已加载类的内部表。编译方法的内存由实时编译器分配，该编译器通常在本机代码中实现。然而，类的集合不可信域（例如，移动代理）被允许访问的权限是有限的，并且为J-SEAL 2内核所知。因此，内核使用近似值来计算类，近似值与类文件的大小成比例。• 序列化：J-SEAL 2使用Java序列化来创建跨域边界传输的消息。当接收域打开一条消息时，它将使用接收域的类加载器解析类名进行解析初始化要求本机方法在不调用其构造函数的情况下分配对象。J-SEAL2通过在消息中存储每种类型的对象数量（这是序列化对象图的一部分）解决了这个问题。接收方在对消息进行序列化之前执行资源检查。• 对象克隆：Java支持对象克隆来创建对象的浅拷贝.浅拷贝由本机方法分配。一个简单的解决方案是禁止不受信任的域使用对象克隆。• 引用：Java引用API提供了一种间接创建类的新实例的机制。对象由本机代码分配。J-SEAL 2简单地防止不受信任的域使用接收API。4评价虽然在J-SEAL 2中，存储器控制的开销与JRes9 [10]引起的开销相当，但必须仔细检查基于字节码重写技术的CPU控制的开销，因为以前没有使用过这种方法。在本节中，我们将展示一些初始性能测量结果，以证明我们完全可移植的CPU计费实现所带来的开销在现代JVM实现上是可以接受的。我们测量了两个著名的微基准，Fib-用于计算斐波那契数的9对于每250个字节码指令分配一个新对象的应用程序，如果没有超出内存限制，则内存控制小于18%10我们并不测量调度程序所引起的CPU控制开销，因为通过选择适当的时间片，它总是可以保持很小11借助我们的字节码重写工具，我们还测量了记账开销SPEC JVM98基准测试。由于篇幅所限，我们无法BINDER，HULAASANDVillaZO'N11表1总结了我们的测量结果，这些测量结果是在具有5种不同JVM实现的Win-NT 4.0工作站（Intel Pentium II，400 MHz时钟速率）上收集的。为了最小化编译和垃圾收集的影响，所有结果代表5个不同测量的中值。对于每个度量，表1显示了微基准的执行时间（以毫秒为单位），以及与重写版本相比的原始代码的加速。我们测量了在没有任何优化的情况下重写的代码，以及应用一些简单的优化规则所产生的代码对于每个JVM实现，我们应用了一组优化，以获得最佳结果。表1CPU记帐的开销（以毫秒为单位的时间）。Sun JDK 1.3Sun JDK 1.2.2IBM JDK 1.3经典（JIT）经典（口译员）热点客户端经典（JIT）热点Server 2.0Fib原始13029（1，00）1542（1，00）1031（1，00）1032（1，00）991（1，00）重写22933（1，76）2123（1，38）1773（1，72）1502（1，46）1522（1，54）优化16825（1，29）1732（1，12）1432（1，39）1232（1，19）1131（1，14）排序原始16954（1，00）1812（1，00）1212（1，00）1352（1，00）782（1，00）重写44344（2，62）2774（1，53）2434（2.01）2564（1，90）2323（2，97）优化34650（2，04）2423（1，34）1513（1，25）2143（1，59）1543（1，97）我们对递归斐波那契方法的测量表明，我们的优化可以将现代JVM实现（如Sun的Hotspot VM和IBM的Classic VM）的会计开销减少到12-19%。这些结果还表明，传递额外的方法参数（CPU帐户）的开销相当小。迭代冒泡排序基准产生更多的开销，因为记账指令代表重写代码的主要部分并且不能从循环中移除，即，冒泡排序基准的结果示出了在实际应用中预期的性能5相关工作我们区分两类相关的工作添加到Java的资源控制：那些有安全作为主要目标，和那些遵循其他动机。在本文中展示所有结果。然而，表1中给出的值代表实际应用。BINDER，HULAASANDVillaZO'N125.1出于安全目的与现有的在Java中实现资源控制的建议相比，我们从两个方面对我们的方法进行了广泛的区分：第一，模型是否支持基于进程的方法，为每个应用程序定义了明确的域边界和资源分配，第二，在何种程度上实现是可移植的。JRes [10]是一个资源控制系统，它考虑了CPU、内存和网络资源消耗。 JRes的资源管理模型在单个Java线程级别工作;换句话说，没有将应用程序作为一组线程的概念，因此资源控制策略的实现是繁琐的。JRes是一个纯粹的资源会计系统，不强制任何域的分离;涵盖这另一方面是J-Kernel [26]的目标，这是同一研究团队的一个补充项目。对于它的实现，JRes不需要对JVM进行任何修改，而是依赖于字节码重写和本机代码库的组合。要执行CPU记帐，JRes的方法是对底层OS的调用，这需要访问本机代码12。对于内存核算，它基本上使用字节码重写，但仍然需要支持本机方法来计算数组对象占用的内存Ka eOS [1]是一个Java运行时系统，它支持操作系统对进程的抽象，以将应用程序彼此隔离，就像它们在自己的JVM上运行由于Ka eOS，一个免费提供的Ka e虚拟机的修改版本[27]，它可以实现比字节码重写技术更高精度的资源控制，其中例如，存储器核算被限制为控制在公共堆中消耗的各个量，并且其中CPU控制不核算为各个应用工作的公共垃圾收集器所花费的时间。Ka eOS的方法应该通过设计产生更好的性能，但本质上是不可移植的。这意味着在编译器和标准JVM中发现的优化并没有从以下方面受益：在最近的一份报告中，[2]作者报告说，在没有拒绝服务攻击的情况下，IBMAlta由与Ka eOS相同的团队开发，[24]是一个基于Fluke分层过程模型的原型，并在Ka e虚拟机上实现。与Ka eOS的主要区别是，一个单一的垃圾收集器负责所有应用程序，Alta通过提供资源控制API完全尊重Fluke的分层进程模型，而Ka eOS只保留了一个更隐式的嵌套CPU和内存管理方案。NOMADS [22]是一个移动代理系统，它能够控制代理使用的资源，包括防止拒绝服务攻击。12更准确地说，JRes中的CPU会计是基于本机线程的，这是一个并非每个JVM都支持的特性。BINDER，HULAASANDVillaZO'N13NOMADS执行环境基于Java兼容的VM，即Aroma VM，每个代理都实例化了一个副本。在NOMADS中没有资源控制模型或API;资源是手动管理的依赖于一个专门的VM，它的开销比我们的方法要小;然而，目前还没有实现CPU控制。在文献中提出了许多其他系统，但没有一个像JRes，Alta，Ka eOS和NOMADS那样完整。[3]中提供了一个很好的最近总而言之，我们可以说J-SEAL 2提出了一个受Alta和J-Kernel启发的保护模型，以及一个更让人想起JRes的内存会计实现。5.2其他以Java为中心的资源控制有几个研究方向，其中设计的环境和分析工具或多或少可以利用本文中公开的相同目标。Real-Time for Java Experts Group [8]已经发布了一项向Java添加实时扩展的提案。这项工作的一个重要重点是确保可预测的垃圾收集特性，以满足实时guarantees。例如，该规范提供了具有有限生命周期的作用域内存区域，可以使用本文中描述的J-SEAL 2扩展来实现（或至少模拟）。另一个实时系统PERC [19]扩展了Java以支持实时性能保证。为此，PERC系统分析Java字节码以确定存储器需求和最大执行时间，并将该信息馈送到实时调度器。实时系统的目标是提供精确的保证，例如最坏的时间执行;另一方面，我们的重点是计算近似的资源消耗，以防止拒绝服务攻击。我们更感兴趣的是应用程序的相对价值，而不是绝对价值。这一点可以通过以下事实得到证实：我们并不试图估计它们的实际CPU消耗，而是比较各自执行的字节码数量。Profilers构成了另一类与资源控制有许多共同点的工具：两者都旨在收集有关资源使用的然而，Profilers旨在帮助开发人员优化其应用程序的效率，而不是从外部控制其资源消耗。Java Virtual Machine ProfilingInterface（JVMPI）[21]是由Sun创建的一个API;它是一组指向JVM的钩子，可以发出有趣的事件，如线程启动和对象分配。Java UsageMonitor（JUM）[11]是一个一个建立在JVMPI上的工具，帮助开发人员确定应用程序的不同线程消耗了多少CPU，以及它们使用了多少内存。JUM需要本机代码从底层操作系统获取有关CPU时间如何分配的信息，因此是不可移植的。BINDER，HULAASANDVillaZO'N14有趣的是，JUM还能够解释由本机代码分配的对象。但是，JUM无法强制执行内存限制。虽然J-SEAL 2允许对内存资源进行精确的预先核算，其中在线程超过其内存限制之前生成过度使用异常，但基于JUM的资源控制机制只能在检测到内存过度使用之后才能做出反应。除了这些限制，JVMPI是一个实验性的接口，它还不是一个标准的profiling接口。最后，我们提到了一些依赖于基于经济学的理论的方法，使用虚拟货币来实现并发应用程序的自然负载平衡，以及在开放和分布式环境中回收未使用的资源，预期的副作用是防止拒绝服务攻击[23]。然而，我们的重点更多地放在如何在特定平台Java上实现基本的资源会计机制，而不是设计高级和分布式资源分配策略。尽管如此，尽管本文的精神相当保守，但它并不排除将目前描述的技术应用于开放计算市场的实现。6现状和结论虽然字节码重写工具的第一个版本已经完成，但将完全资源控制集成到J-SEAL 2内核中的工作仍在进行中。在我们的待办事项列表中，还包括开发高级编程工具，以支持比J-SEAL 2内核生成的过度使用异常更友好的事件通知机制。用户指定的阈值应使应用程序能够在实际过度使用发生之前及时收到警告。虽然其他方法专注于高性能，或演示Java运行时系统的长期，深入的重新设计，但我们的建议可能会被粗略地描述为基于语言的补丁。我们的资源控制系统确实不能提供相同水平的测量精度和执行速度。另一方面，J-SEAL 2完成了将应用程序彼此隔离的工作，特别是防止来自执行平台内部的拒绝服务攻击。此外，我们的方法的完全兼容性和可移植性使其立即可用于大型分布式代理系统的好处，特别是当涉及移动代码时。确认作者要感谢Rory G.维达尔。更多的荣誉要归功于Julien Francioli、RudolfFreund、Andreas Krall、Patrik Mihailescu、Klaus Rapf和Jan Vitek的宝贵支持。BINDER，HULAASANDVillaZO'N15引用[1] G. 巴克街和W街。阿谢在Java中绘制红线在第七届IEEE操作系统热点上，美国亚利桑那州里奥里科，1999年[2] G.后退，W。Hsieh，andJ. Lepreau. Ka eOS中的进程：Java中的隔离、资源管理和共享。在第四届操作系统设计与实现研讨会（OSDI'2000）会议录两千[3] G. Back，P. Tullmann，L. Stoller，W. Hsieh，andJ. Lepreau. Java操作系统的设计技巧。2000年USENIX年度技术会议集，加利福尼亚州圣地亚哥，2000年6月[4] G. Back，P. Tullmann，L. Stoller，W. C. Hsieh，andJ. Lepreau. Java操作系统：设计与实现技术报告UUCS-98- 015，犹他大学计算机科学系，2009年8月。1998年6月[5] W. 活页夹。J-SEAL 2-一个在IAT1999年[6] W.活页夹。J-SEAL 2移动代理内核的设计与实现。在2001年应用程序和互联网研讨会（SAINT-2001），圣地亚哥，加利福尼亚州，美国，1月。2001年[7] W. Binder，J. Hulaas和A. 别墅在那边。J-SEAL 2中的资源控制。技术报 告 Caudaldu CUI No. 124 ， 日 内 瓦 大 学 ， 10 月 。 两 千ftp://cui.unige.ch/pub/tios/papers/TR-124-2000.pdf。[8] G. 博莱拉湾 Brosgol，P. Dibble，S. Furr，J.Gosling，D. 哈丁，和M. 特恩布尔Java的实时规范。Addison-Wesley，Reading，MA，USA，2000.[9] C. 布莱斯和J。维泰克JavaSeal移动代理内核。在First InternationalSymposium on Agent Systems and Applications（ASA1999年[10] G. Czajkowski和T.冯·埃克塞特。JRes：Java的资源会计接口。在Proceedingsof the 13th Conference on Object-Oriented Programming ， Systems ，Languages ， and Applications （ OOPSLA-98 ） ， volume 33 ， 10 ofACMSIGPLAN Notices，pages 211998年18日Press.[11] F.- X.乐卢阿恩朱姆，一Java使用监视器.Web页http://www.iro.umontreal.ca/~lelouarn/jum.html。[12] B. Ford，M.作者声明：R.McGrath，and P. Tullmann. Kubuke内核中的接口和执行模型。在第三届操作系统设计与实现研讨会（OSDI-99）会议录中，第101-116页1999年12月22日Usenix协会。[13] B. Ford和S.苏萨拉CPU继承调度。Usenix协会第二届操作系统设计与实现研讨会（OSDI），第91-105页，1996年BINDER，HULAASANDVillaZO'N16[14] M. Godfrey，T. Mayr，P. Seshadri，and T.冯·埃克塞特。安全和可移植的数据库可扩展性。在数据管理ACM SIGMOD国际会议（SIGMOD-98）的会议记录中，ACM SIGMOD记录的第27卷，第2卷，第390Press.[15] J. Gosling，B. Joy和G. L.斯蒂尔Java语言规范。Java系列。 Addison-Wesley，Reading，MA，USA，第一版，1996年。[16] J. 胡拉斯湖Gannoe，J. Francioli，S. Cha ch kov，F. S chütz和J. 伤害。使用移动代理的互联网域名电子商务。在第二届电信和电子商务国际会议（ICTEC'99），纳什维尔，田纳西州，美国，10月。1999年[17] T. Lindholm和F.耶琳Java虚拟机规范Addison-Wesley，Reading，MA，USA，第二版，1999.[18] L. Moreau和C.奎内克Quantum的设计和语义：一种在分布式计算中控制资源消耗在Usenix Conference on Domain-Specific Languages（DSL一九九七年。[19] K.尼尔森 Java实时 实时系统杂志，11（2），1996年。[20] T. Suganuma，T.小笠原湾Takeuchi，T.Yasue，M.Kawahito，K.石崎，H. Komatsu 和 T. 中 谷 IBM Java Just-in-Time 编 译 器 概 述 。 IBM SystemsJournal，39（1）：175[21] Sun Microsystems 公 司 Java 虚 拟 机 剖 析 器 接 口 （ JVMPI ） 。 网 址 ：http://java.sun.com/j2se/1.3/docs/guide/jvmpi/index.html。[22] N. Suri，J. M. Bradshaw，M.R. Breedy，P.T. Groth，G.A. 希尔河，巴西-地亲爱的，T. S.米特罗维奇湾R. Pouliot和D. S.史密斯NOMADS：一个强大而安全的移动代理系统。In C.谢拉湾Maria和J. S. Rosenschein，编辑，第四届自主代理（AGENTS-00），第163-164页，纽约，2000年6月3日至7日。Press.[23] C. F.楚丁移动代码的开放资源分配。在第一次研讨会上移动代理，柏林，德国，4月。一九九七年。[24] P. Tullmann和J.Lepreau。嵌套的Java进程：移动代码的操作系统结构。第八届ACM SIGOPS欧洲研讨会，葡萄牙辛特拉，9月。1998.[25] Vitek和G.卡斯塔尼亚Seal：一个安全移动计算的框架。互联网编程语言，1999年。[26] T.冯·埃克塞特，C.- C.张，G. Czajkowski和C.霍布利策J-Kernel：一个基于能力的Java操作系统计算机科学讲义，1603：369[27] T.威尔金森。嘉江-一Java虚拟机Web页在http://www.kaffe.org/。