用于资源受限设备的虚拟执行系统.pdf

一种被配置成在资源受限设备中使用的虚拟执行系统。该资源受限设备包括操作系统和包括指令的应用程序。该虚拟执行系统包括执行引擎，其被配置成执行应用程序以及帮助应用程序与操作系统的兼容。非功能方面表征指令和操作系统。该执行引擎可访问非功能方面，并且基于该非功能方面在应用程序的执行期间实现改进。

1.  一种被配置成在资源受限设备(12)中使用的虚拟执行系统(20)，所述资源受限设备包括操作系统(28)和具有指令(16)的应用程序(14)，所述虚拟执行系统包括：
a.被配置成执行所述应用程序以及帮助所述应用程序与所述操作系统的兼容的执行引擎(24)。
b.其中
i.非功能方面表征所述指令和所述操作系统，
ii.所述执行引擎可访问所述非功能方面，以及
iii.所述执行引擎基于所述非功能方面在所述应用程序的执行期间实现改进。

2.  如权利要求1所述的虚拟执行系统(20)，其特征在于，由所述执行引擎(24)实现的所述改进选自由影响性能的改进、影响存储器需求的改进、安全性改进和及时性改进组成的组。

3.  如权利要求1或权利要求2所述的虚拟执行系统(20)，其特征在于：
a.所述操作系统(28)展示应用程序接口和运行时结构(30)；
b.所述虚拟执行系统展示编程模型；以及
c.所述执行引擎(24)利用所述非功能方面来帮助从所述虚拟执行系统的编程模型到所述操作系统的应用程序接口和运行时结构的映射。

4.  如前述任一权利要求所述的虚拟执行系统(20)，其特征在于，所述非功能方面选自由及时性信息；安全性信息；函数调用信息；资源需求信息；存储器限制信息；安全约束信息；网络生存期信息；实时信息；能量消耗信息；执行模式信息；描述托管函数、应用程序特有特性、所述设备(12)的资源约束及所述操作系统(28)的特性之间的关系的信息组成的组。

5.  如前述任一权利要求所述的虚拟执行系统(20)，其特征在于，所述非功能方面用以中间语言编码的元数据来描述。

6.  如权利要求5所述的虚拟执行系统(20)，其特征在于：
a.所述虚拟执行系统包括选自由公共语言基础结构和JAVA虚拟机组成的组的运行时技术；以及
b.所述中间语言选自由公共中间语言和JAVA字节码组成的组。

7.  如前述任一权利要求所述的虚拟执行系统(20)，其特征在于，所述操作系统(28)选自由SYMBIAN操作系统和TINYOS操作系统组成的组。

8.  一种资源受限设备(12)，包括：
a.第一计算机可读介质(18)，其包括具有指令(16)的应用程序；
b.第二计算机可读介质(32)，其包括展示应用程序接口和运行时结构(30)的操作系统(28)；以及
c.虚拟执行系统(20)，其被配置成帮助所述应用程序与所述操作系统的兼容以及展示编程模型；
d.其中：
i.非功能方面表征所述指令和所述操作系统，
ii.所述虚拟执行系统可访问所述非功能方面，
iii.所述虚拟执行系统基于所述非功能方面在所述应用程序的执行期间实现改进，以及
iv.所述虚拟执行系统利用所述非功能方面来帮助从所述虚拟执行系统的编程模型到所述操作系统的应用程序接口和运行时结构的映射。

9.  如权利要求8所述的资源受限设备(12)，其特征在于，所述非功能方面选自由及时性信息；安全性信息；函数调用信息；资源需求信息；存储器限制信息；安全约束信息；网络生存期信息；实时信息；能量消耗信息；执行模式信息；描述托管函数、应用程序特有特性、所述设备的资源约束及所述操作系统(28)的特性之间的关系的信息组成的组。

10.  如权利要求8或权利要求9所述的资源受限设备(12)，其特征在于，所述资源受限设备选自由移动电话、个人数字助理、手持式计算机、游戏控制台、机顶盒、基于卫星的定位设备和传感器节点组成的组。

11.  如权利要求8到10中的任一项所述的虚拟执行系统(12)，其特征在于，所述非功能方面用以中间语言编码的元数据来描述。

12.  一种用于提高资源受限设备(12)中的虚拟执行系统(20)的性能的方法，所述资源受限设备包括操作系统(28)和包括指令(16)的应用程序(14)，所述方法包括：
a.标识所述指令和所述操作系统的非功能方面；
b.向所述虚拟执行系统提供所述非功能方面；以及
c.由所述虚拟执行系统在所述应用程序的执行期间使用所述非功能方面。

13.  如权利要求12所述的方法，其特征在于，还包括：
a.标识在所述操作系统(28)中展示的应用程序接口和运行时结构(30)；
b.在所述应用程序(14)的执行期间考虑所述应用程序接口和运行时结构以及所述非功能方面；以及
c.将所述指令(16)映射到所述应用程序接口和运行时结构。

14.  如权利要求13所述的方法，其特征在于，所述虚拟执行系统(20)展示编程模型，并且还包括将所述编程模型映射到所述应用程序接口和运行时结构(30)。

15.  如权利要求12到14中的任一项所述的方法，其特征在于：
a.所述操作系统(28)包括具有安全限制的安全模型；
b.所述虚拟执行系统(20)向应用程序员展示所述安全模型；以及
c.所述应用程序员能够在逐个情况的基础上决定如何处理所述安全限制。

16.  如权利要求12到15中的任一项所述的方法，其特征在于，所述虚拟执行系统(20)提供线程(64)，并且所述操作系统(28)提供服务器(54)；并且所述方法还包括对所述线程排序以使得所有所述线程能够访问所述服务器。

17.  如权利要求16所述的方法，其特征在于，还包括为需要服务器会话的每个对函数的访问以及为所述虚拟执行系统(20)中的每个线程(64)创建单独的服务器会话。

18.  如权利要求12到17中的任一项所述的方法，其特征在于，所述操作系统(28)提供服务器(54)，并且所述方法还包括创建到所述服务器的会话，其中所述虚拟执行系统(20)被配置成管理所述会话，并且所述会话在选自由以下各项构成的组的方法中创建：在所述虚拟执行系统的启动期间创建到所有服务器的会话，以及在运行时创建到所述服务器的会话。

19.  如权利要求12到18中的任一项所述的方法，其特征在于，所述虚拟执行系统(20)被配置成帮助抢先的多任务处理，并且所述操作系统(28)展示非抢先的多任务处理模型；并且所述方法还包括将所述虚拟执行系统中的抢先的多任务处理映射到所述操作系统的非抢先的多任务处理模型。

20.  如权利要求12到19中的任一项所述的方法，其特征在于，所述虚拟执行系统(20)被配置成提供抢先调度的线程(64)以执行任务并且知道什么函数被映射到所述操作系统(28)中的异步函数调用，并且所述操作系统被配置成基于协作多任务处理来实现线程模型并且提供轻量线程模型；所述方法还包括选自由以下各项组成的组的步骤：
a.通过在单个线程中执行一个以上的任务来减少抢先调度的线程的数量；以及
b.使用所述轻量线程模型来提高执行并发任务的效率。

用于资源受限设备的虚拟执行系统
本技术领域一般是虚拟执行系统的领域。更具体地，本技术领域涉及在资源受限设备中虚拟执行系统的使用。
资源受限设备是通常具有比台式计算机大得多的对计算资源和存储器的约束的电子设备。资源受限设备的示例包括移动电话、个人数字助理、手持式计算机、游戏控制台、机顶盒、基于卫星的定位设备(例如，全球定位系统(“GPS”)设备)和传感器节点。资源受限设备是在一设备中帮助虚拟执行环境的虚拟执行系统(也被称为运行时环境)感兴趣的目标。虚拟执行系统是能够以软件或以硬件和软件的组合实现的程序执行系统，其使高级应用程序能够在不考虑该应用程序与设备的操作系统或硬件的兼容性的情况下执行。因此，虚拟执行系统向应用程序提供了与设备的操作系统或硬件的独立性。
在资源受限设备中使用虚拟执行系统的主要原因是通常难以在资源受限设备上进行本机编程，即使用设备的内部文件格式的编程。难以在资源受限设备上进行本机编程是因为在那些资源受限设备上提供的本机编程模型(包括应用程序接口(“API”)，即，用于创建应用程序的例程、协议和工具，以及可用于编写应用程序的编程概念)和编程语言经常难以理解并且没有为应用程序员提供简单的接口。
运行时技术，即在应用程序的执行期间操作并且帮助虚拟执行系统的技术，有可能显著改善在资源受限设备上实现应用程序的过程。示例运行时技术包括以下：由加利福尼亚州的圣克拉拉市的Sun微系统有限公司创建的JAVA虚拟机(“JVM”)；以及作为国际标准的公共语言基础结构(“CLI”)。公共语言运行库(“CLR”)是由华盛顿州雷蒙德市的微软公司创建的CLI的实现。运行时技术允许应用程序用各种高级语言的任一种来编写并且仍然在不同的系统环境中执行。应用程序开发者将符合运行时技术的这些高级语言编译成中间语言，例如，公共中间语言(“CIL”)或JAVA字节码。该中间语言进而在程序执行期间被变换成特定于设备的体系结构的本机代码。
虽然虚拟执行系统从应用程序员的观点来看是极度需要的，但是在资源受限设备上使用运行时技术的主要缺点是对于该设备的性能损失。关于该性能损失的原因之一是由虚拟执行系统的运行时技术支持的编程模型与同资源受限设备的操作系统和硬件相关联的编程模型之间的差异。该性能损失是不合需要的，并且对于资源受限设备而言是不容许的。
与在资源受限设备中使用虚拟执行系统相关联的另一个问题是资源受限设备的操作系统所提供的能力及所具有的限制与包括在台式系统中的操作系统不同。因此，将由虚拟执行系统展示的编程模型映射到资源受限设备中的操作系统的API和运行时结构是具有挑战性的。与此同时，应用程序员期望利用底层操作系统的附加能力。

概述
提供本概述以便以简化的形式介绍将在以下详细描述中进一步描述的一些概念。该概述不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。
在详细描述中更详细描述的各实施例包括虚拟执行系统、资源受限设备和用于提高资源受限设备中的性能的相关方法。一个示例性实施例是一种被配置成在资源受限设备中使用的虚拟执行系统。该资源受限设备包括操作系统和包括指令的应用程序。该虚拟执行系统包括执行引擎，其被配置成执行应用程序以及帮助应用程序与操作系统的兼容。非功能方面表征指令和操作系统。该执行引擎可访问非功能方面，并且基于该非功能方面在应用程序的执行期间实现改进。
现在将作为示例，参考所附附图描述本发明的各实施例，附图中：
图1是包括在资源受限设备中的通用分层结构的框图。该通用分层结构包括应用程序、虚拟执行系统、平台自适应层、操作系统和硬件。
图2是表示图1的虚拟执行系统和/或平台自适应层所采取的步骤的示例性算法的流程图。
图3是对套接字函数的调用的平台自适应层实现的框图。
图4是对套接字函数的调用的第一平台自适应层实现的框图，其中应用程序线程被表示为活动对象。
图5是对套接字函数的调用的第二平台自适应层实现的框图，其中应用程序线程被表示为活动对象。
图6是示出在有和没有附加平台自适应层线程的情况下在SYBMIAN控制台上的打印语句的性能的曲线图。
图7是示出在有和没有中间平台自适应层线程的情况下低复杂度操作的性能的曲线图。
图8是示出应用程序线程数量对在仿真器上执行排序的平台自适应层函数的性能的影响的曲线图。
图9是示出应用程序线程数量对在资源受限设备上执行排序的平台自适应层函数的性能的影响的曲线图。
图10是示出使用托管与非托管线程对资源受限设备的性能的影响的曲线图。
图1是示例性资源受限设备的软件和硬件分层体系结构10的框图。在设备12中示出包括指令16并且存储在第一计算机可读介质18中的应用程序14；包括类库22和执行引擎24的虚拟执行系统20；平台自适应层(“PAL”)26；操作系统28，其展示，即，提供、支持、和/或允许通过提供明确定义的接口、一组API和内部数据结构30(该内部数据结构在运行时期间被称为“运行时结构”)来使用底层服务并且存储在第二计算机可读介质32中；以及硬件34，例如，资源受限设备的微处理器、随机存取存储器(“RAM”)、只读存储器(“ROM”)和蓝牙硬件组件。因此，当认为操作系统展示一组API和内部数据结构时，这意味着该操作系统具有可被应用程序、应用程序员、和/或虚拟执行系统使用的一组API和内部数据结构。
PAL 26与虚拟执行系统20接口并且直接与操作系统28和硬件34进行通信。PAL是处理底层操作系统服务对虚拟执行系统的编程模型的自适应的组件的逻辑抽象。操作系统用作硬件与在设备12上运行的软件之间的接口。每个计算机可读介质18和32可以是例如，RAM、ROM、EEPROM、闪存、CDROM、DVD、光盘、磁带盒、磁带、磁盘驱动器、或可用于存储信息的任何其他介质。同样，第一计算机可读介质18和第二计算机可读介质32可包括在单个计算机可读介质中。
类库22包括被执行引擎24使用的数据。执行引擎被配置成执行应用程序14以及帮助应用程序与操作系统28的兼容。该执行引擎读取中间语言代码、利用来自类库的数据、并且转换该信息以使其可被设备的操作系统和硬件34使用。PAL被配置成将来自应用程序的指令映射到在底层操作系统中的API和运行时结构30。图1是示例性的，并且可取决于资源受限设备12的独特特性从图1中添加、组合、或移除各种硬件和/软件组件。
缩小由虚拟执行系统20支持的编程模型与由资源受限设备12支持的编程模型之间的信息差异是重要的。以下讨论的各示例实施例通过增加虚拟执行系统的编程模型对资源受限设备的编程模型的认识来缩小该信息差异。更具体地，各实施例使虚拟执行系统，尤其是结合PAL 26的执行引擎24更容易将来自该虚拟执行系统使用的中间语言的指令映射到底层操作系统28的合适的API和运行时结构30。这些映射的示例包括以下：将虚拟执行系统中所支持的线程化模型映射到由资源受限设备的操作系统展示的线程化模型，以及映射虚拟执行系统中所支持的访问文件的方法以使其有效地考虑底层操作系统的安全限制。
通过增加虚拟执行系统20，尤其是执行引擎24对与将由虚拟执行系统执行的应用程序的指令16以及设备的操作系统28相关的非功能方面的认识来做出性能提高。这通过用描述非功能方面的元数据扩充应用程序指令来完成。这些非功能方面可包括，例如，关于及时性、安全性、资源需求、网络生存期、实时方面、能量消耗、和/或执行模式的信息。非功能方面向虚拟执行系统提供关于如何通过考虑应用程序14的需求特性以及设备的底层操作系统的特性来优化性能的额外知识。具体地，非功能方面被虚拟执行系统用来找出设备的操作系统中适当的API和运行时结构30。
以下是虚拟执行系统20所采取的示例步骤。首先，分析由操作系统28提供给资源受限设备12的API和运行时结构30。其次，找出如何将虚拟执行系统的编程模型(例如，API和运行时结构)映射到底层操作系统的方法。第三，在PAL 26中实现这些不同的方法(任选地，对执行引擎24的添加可能是必须的)。第四，允许执行引擎在不同的实现之间切换。第五，将描述非功能方面的元数据添加到指令。元数据的添加可由程序员在指令层上完成。元数据的添加还可基于简档对于特定类型的所有指令自动完成。第六，执行引擎能够使用非功能方面来提供到操作系统的改进的映射，或利用最初并未包括在虚拟执行系统的编程模型中的操作系统特征，例如，关于访问操作系统中的套接字/文件的安全问题。
表示虚拟执行系统20结合PAL 26所采取的步骤的示例性算法36在图2中示出。该算法可以用存储在计算机可读介质18和32中的计算机可读介质指令来实现。在该算法开始38之后，下一步骤40是使虚拟执行系统标识应用程序的指令16的非功能方面和操作系统28的非功能方面。在步骤42处，将非功能方面提供给虚拟执行系统，其在步骤44处在应用程序14的执行期间使用该非功能方面。接着，在步骤46处，虚拟执行系统结合PAL标识操作系统中的API和运行时结构30。在步骤48处，虚拟执行系统在应用程序的执行期间考虑该API和运行时结构以及该非功能方面。在步骤50处，PAL结合虚拟执行系统将指令映射到该API和运行时结构。该算法在步骤52处结束。
被虚拟执行系统20利用的非功能方面使用与该虚拟执行系统兼容的某种形式的中间语言编码的元数据来描述。给定该元数据，虚拟执行系统能够执行帮助将运行时技术部署在资源受限设备12上的各种各样的优化。例如，如果某些实时方面在执行一功能时是重要的，则虚拟执行系统能够基于底层操作系统28的能力来自动确定特定指令的优先级。同样，关于安全问题的信息对于提高的性能而言是重要的。例如，在没有关于安全约束的附加信息的情况下，必须支持最强的安全机制，这可导致性能损失。此外，关于执行模式的信息(例如，一函数是否意味着对底层操作系统的异步函数调用)可用于找出用于提高的性能的合适API和运行时结构30。
在一个实施例中，资源受限设备12中的操作系统28包括API和运行时结构30，其被配置成执行作为在.NET环境中运行的代码的托管代码。该托管代码的执行由CLR控制，CLR是.NET应用程序在其中运行的运行时环境。CLR被分层在.NET应用程序与底层操作系统之间。在执行期间，CLR能够停止执行引擎24并且检索以中间语言编码的信息，例如，元数据。
为了允许必须的性能提高，附加信息被嵌入到托管代码中以允许执行引擎24中和PAL 26处的优化。该附加信息对于例如，调用机制(“PInvoke”)等各种编程机制而言是重要的，调用机制是.NET语言用于调用动态链接库(“DLL”)中的非托管函数的机制。附加信息对于托管代码库而言也是重要的。对于将附加数据注入托管代码，CLI支持可扩展元数据模型。
一般地，使用元数据来描述CLI中的公共类型系统(“CTS”)中的类型。CTS是用于定义如何在运行时环境中声明、使用和管理各种类型的数据的规范。元数据可在运行时被执行引擎24访问以加载类或执行运行时检查。在资源受限设备12上，使用元数据来使虚拟执行系统20与PAL 26能够一起通过考虑底层操作系统28的API和运行时结构30来执行更多的优化。在如同C#的CLI编程语言中，属性是将元数据添加到例如数据、方法、类和接口的机制。对于自定义属性的使用的替换方案是直接扩展PInvoke机制的句法以允许性能提高；这也将影响可被执行引擎访问的元数据。
附连到PInvoke机制和其他指令16的这种元数据允许执行引擎24动态地执行优化以将托管代码指令映射到底层操作系统28的合适API和运行时结构30上。所附连的元数据描述将由虚拟执行系统20执行的指令的非功能方面。例如，考虑标准PInvoke机制，元数据主要着重于功能方面，诸如函数名、函数标号、自变量类型、调用约定和数据编组(见ECMA标准ECMA-335的15.5节)等。此处，PInvoke机制由非功能方面来扩展，这允许PAL中的优化。这些非功能方面的示例是关于安全约束的信息、关于函数调用的侧放作用的信息、关于定时问题的信息和关于执行模式的信息，例如，函数是否是异步的。
以下所讨论的在三个示例中的特定非功能方面提供关于函数是否映射到异步函数调用、关于安全约束以及关于底层操作系统28的特性的信息。在这三个示例中，讨论了用于处理用于由英国伦敦市的Symbian有限公司提供的SYMBIAN操作系统的虚拟执行系统20中的安全、存储器和线程化问题的特定技术。这三个示例实现CLR到SYMBIAN操作系统的移植，即，应用程序14从一种类型的计算机到另一种类型的计算机的转移。SYMBIAN操作系统是用于启用数据的移动电话，例如被配置成访问因特网的移动电话的操作系统。SYMBIAN操作系统提供一种与由CLR提供的编程模型不同的编程模型，并且CLR/SYMBIAN接口示出与将运行时技术移植到资源受限设备12相关联的某些困难。
虽然以下讨论的重点将会在符合CLI的虚拟执行系统20上，但是本文中包括的示教可应用于不同的运行时技术，例如JVM，并且应用于除了SYMBIAN操作系统之外的不同的操作系统28，例如通常在小型传感器设备上使用的TINYOS。
示例1：SYMBIAN智能电话上的安全约束
当将虚拟执行系统20移植到资源受限设备12时，期望维持该设备的底层操作系统28的附加安全机制。即使安全机制并非可直接被由虚拟执行系统支持的编程语言14访问，亦是如此。附加安全约束常常是对可靠性的特殊需求以及设备上的资源限制的结果。在该示例中，讨论当前作为智能电话的主流操作系统的SYMBIAN操作系统中的安全约束。具体地，在该示例中，安全约束被集成到虚拟执行系统中并且使其可被应用程序员访问。
参考图3，假设在本节中讨论的示例SYMBIAN安全约束提高可靠性，因为它限制对资源的访问并且需要显式建立连接来访问资源。SYMBIAN操作系统28提供一组所谓的服务器54，其是该操作系统的本地服务提供方。使用服务器来访问特定资源。存在用于访问文件系统功能，例如用于处理位图或窗口、用于发送诸如短消息服务(“SMS”)或多媒体消息服务(“MMS”)等消息、用于通过套接字接口访问网络、以及甚至用于打印消息的服务器。一般地，存在用于除了简单数学计算之外几乎所有一切的服务器。服务器通常提供异步函数以帮助SYMBIAN的协作多任务处理的模型。
每个服务器54在不同的线程56或进程上运行，并且因此是与各个应用程序14分离的。客户机与服务器之间的通信在被指定为存在于应用程序线程58与服务器线程之间的会话上发生。所导致的附加访问限制或安全约束是只有创建该会话的线程被允许使用该会话。这保证了可在任何会话上强制实施安全性，并且该安全性能够对设备12的稳健性作出贡献。
虚拟执行系统20通常实现绕开可能并非始终是合乎需要的这一附加安全保护的机制。相反，可以相信，虚拟执行系统应当知道并且遵从资源受限设备12的特殊限制和资源约束以提高稳健性和性能。
图3是示出用于绕开SYMBIAN的安全保护(见图3的右边部分60)的机制，并且将其与典型的台式操作系统28(见图3的左手侧62)上的PAL实现相比较的框图。如从图3的左手侧可以看出，对托管框架中的套接字函数的调用可被直接映射到底层操作系统的套接字函数。对于底层SYMBIAN操作系统，从不同线程64调用的send()(发送)操作由于安全限制而存在问题。具体地，只有打开到服务器54的连接的线程，在这种情况下是SYMBIAN操作系统(“OS”)套接字服务器，能够与该服务器对话。如果从两个不同线程的调用send()，则这两个不同的线程被直接映射到SYMBIAN套接字函数。这将导致出错，它可导致智能电话在典型使用期间崩溃。
为了允许多个线程64访问套接字服务器54，PAL 26必须引入建立到SYMBIAN套接字服务器的连接的新线程，即，图3所示的PAL套接字线程66。如果不同的线程现在调用.NET send()函数，则该请求被调度以供执行，并且最终由PAL套接字线程来调用。通过使用该配置，只有PAL套接字线程访问套接字服务器从而绕开了安全保护。这种安全保护的绕开在某些情况下可能是可接受的，但是，一般地，该方法是有问题的，因为它取消了底层操作系统28的保护。以下是处理该问题的若干不同的方法。
方法1：
可以使用上述机制来允许不同的线程64共享与服务器54的单个会话。该单个服务器会话由PAL26中的附加线程66来建立，该线程对来自不同的应用程序线程的请求进行排序。该方法的优点是单个服务器会话可被不同的应用程序线程重复使用。该方法的缺点是它以可被不同种类的服务提供方重复使用的附加线程，即调度开销为代价，并且导致SYMBIAN的安全机制的削弱。
方法2：
可能最简单的解决方案是在需要与服务器54进行通信的每个PAL函数中创建服务器会话，即到该服务提供方的连接。在会话建立后，执行该函数，并且然后关闭该服务器会话。与该方法相关联的缺点是因连接建立/关闭导致的性能损失，这在几乎所有PAL函数中将会是必然的。
方法3：
另一方法是为使用由该特定服务器54提供的服务的每个应用程序线程58建立单独的服务器会话。那意味着如果两个线程64使用一服务器，则这两个线程能够建立两个不同的服务器会话；并且由一个线程建立的服务器会话被从该一个线程中调用的函数使用。该方法的优点是它遵从SYMBIAN操作系统28的访问限制，从而如果使用了一个服务器会话，则它始终从该相同线程中出现，即使它是应用程序线程。此外，使用该方法来调用函数更快，因为无需对请求进行排序的独立PAL线程。这意味着该PAL中的附加线程无需线程同步。该方法的缺点是该方法可能导致比第一个方法更多的服务器会话，因为服务器会话并没有在不同的应用程序线程之间共享。
所有以上方法都具有可行的应用领域。然而，由于资源受限设备12的资源约束，令应用程序员决定使用什么特定方法可能变得必须或需要。这可通过使用元数据来完成。例如，如果第三个方法是合乎需要的，则引入创建线程函数的自定义属性，它允许程序员指定将创建附加服务器会话。该附加服务器会话被在该线程64中调用的函数使用。或者，关于采取什么方法的决定也可在程序集层上作出，这意味着元数据属性可指定对于在程序集中创建的所有线程使用什么方法。通过这么做，优化可基于应用程序特有元数据在虚拟执行系统20中实现。
示例2：PAL API和运行时结构的特定于应用程序的自适应
用于处理资源受限设备12的资源限制的现有方法之一是根据特定应用程序14来自适应托管程序集，即，其中代码模块由托管代码(托管代码是将要在虚拟执行系统20中执行的代码)组成的程序集。换言之，给定特定应用程序和一组托管代码库，可以找出该特定应用程序需要该托管代码库的什么子集。因为资源受限设备的存储器约束可以是严格的，所以只有托管代码库的绝对必需的子集和该特定应用程序才被部署在该资源受限设备上。该方法减少了所需存储器数量并且能够显著地提高性能。然而，该方法只影响托管代码而不是虚拟执行系统的非托管代码部分。
变得可能的优化的一简单示例影响执行引擎24的初始化和启动阶段。考虑前一节中的示例1，一个重要的问题是何时创建到服务器54的会话。以下两个方法是可能的。第一，在启动期间创建到所有服务器，例如文件服务器、联网服务器、消息通信服务器和位图服务器的服务器会话以及必需的线程64和API及运行时结构30。该第一方法的优点是只要PAL函数需要，所有必需的API和运行时结构就会在适当的位置。该方法的缺点是那些结构中的大部分可能永远不会被使用，并且可能因此浪费存储器。第二方法是在运行时创建服务器会话和相应的API及运行时结构。在示例1的第三个方法中，这可能在创建线程时发生。否则，服务器会话可以在真正使用特定PAL函数时建立。例如，对文件函数的第一个调用将建立到SYMBIAN文件服务器的连接。
再一次，可以使用该示例的两个方法。虽然一般是优良的，但是该第二方法的缺点是第一次调用访问特定服务器54的函数可能导致多得多的执行时间。如果应用程序14具有在资源受限设备12中并非不常见的某些实时约束，则这就会有问题。
API和运行时结构30的初始化可通过执行对将要执行的应用程序14及托管库中相应元数据的静态分析来改进。静态分析是在应用程序上执行而不执行该应用程序的分析。例如，静态分析可揭示应用程序没有访问文件函数；在这种情况下，无需建立对于与服务器54进行通行所必需的服务器会话和线程64。托管代码库中的元数据同样是必需的以指定哪些托管函数(通过PInvoke机制)访问与特定服务器对话的SYMBIAN函数。这些注释对于虚拟执行系统20中的许多有用的跨层优化而言是必需的。
此外，虚拟执行系统的非托管占用量，即没有托管代码库的部分可能是相当大的。为了具有用于资源受限设备12的虚拟执行系统，可能必须根据将要在这些设备上执行的应用程序14的要求来自适应包括在该虚拟执行系统的非托管部分中的模块。
建议的方法是将关于托管部分的同一种优化应用于虚拟执行系统的执行引擎24的非托管部分。这意味着基于必须取决于具体操作系统28来包括的(即，对于SYMBIAN所包括的属性将不同于TINYOS或NUT/OS)包括在托管代码库中的元数据，它可通过对将需要PAL模块的托管应用程序的静态分析来找出。例如，如果应用程序14只需要文件功能、消息通信功能、或图形用户界面(“GUI”)功能集，则相应的PAL函数被包括在虚拟执行系统20中并部署在资源受限设备12上。该方法同样只有通过用底层操作系统特有元数据扩充托管代码库才是可能的。只有该元数据才使得所建议的大小的优化成为可能。
乍一看，后一方法显现出看上去像通过PInvoke的标准库加载。例如，假设用于文件访问、联网和GUI功能集的PAL模块被嵌入到单独的动态链接库(“DLL”)中，它是可被WINDOWS应用程序14使用的数据或可执行函数功能的库。WINDOWS是由微软公司创建的。此外，对于该示例，假设存在以下两种具有不同大小限制的存储器18和32：(1)大量非易失性存储器，例如，附连到移动电话用于存储图片的存储卡；以及(2)有限数量的RAM。用于文件访问、联网和GUI功能集的不同PAL模块可被存储到非易失性存储器中并且只在访问该PAL模块的PInvoke发生时才通过LoadLibrary(加载库)函数加载到RAM中。
以上示例具有与其相关联的以下三个问题。第一，PAL模块通常包含所有文件函数或所有联网函数，所以，在实践中，比所需的更大的模块通过LoadLibrary函数加载到有限数量的RAM中。通过对应用程序14的静态分析以及所建议的元数据扩充，PAL模能够只包含必要的函数。第二，在运行时期间，而非在如其通常发生的初始化期间的模块的动态加载可能是不合需要的。这对于具有特定时间约束的应用程序而言尤其如此。第三，大量可用非易失性存储器的假设并非始终是正确的。鉴于此原因，存储器限制在虚拟执行系统20被部署在设备12上时常常是重要的考虑。
当知道应用程序14将要在资源受限设备12上执行时，对这些应用程序的静态分析能够显著改善对必须被部署在该资源受限设备上的虚拟执行系统20的存储器需求。动态优化在这种情况下并不能有所帮助。在实践中，将要执行的应用程序的数量通常非常少。实际上，在大多数情况下，只存在单个应用程序。
示例3：通过利用关于异步函数的知识的优化
该示例示出如何在由虚拟执行系统20提供的不同编程模型，或更精确地而言，在其上方的应用程序编程语言14与底层操作系统28之间高效地映射。具体地，以下示例处理线程处理情况。在该示例中解决的问题是虚拟执行系统通常集中于简单的编程模型，其中开发者不必关心如何手动地在不同任务之间切换。相反，资源受限设备12的操作系统通常只具有对抢先调度的线程64的有限支持。结果，这些操作系统或者是纯粹基于事件的并且将在任务之间显式切换的责任移交给程序员，或者提供具有高度集中于协作多任务处理的编程结构。SYMBIAN操作系统属于后一种类别。尽管SYMBIAN操作系统支持抢先调度的线程，但其编程模型高度集中于协作多任务处理。
本节的目标是示出如何处理不同编程模型之间的差异，以及如何通过使其知道底层编程模型来允许虚拟执行系统20中的优化。具体地，以下是合乎需要的：(1)减少抢先调度的线程64的数量及其在虚拟执行系统中引起的管理开销，以及(2)提高使用由底层操作系统提供的轻量线程模型来执行并发任务的效率。这些目标通过将关于底层编程模型的信息作为元数据嵌入在托管代码中来实现，虚拟执行系统利用该元数据来执行优化。
以下是如何减少线程64的数量的一个示例方法。示例1引入了处理与SYMBIAN操作系统28相关联的安全约束的体系结构。如从图3可以看出，最常见的方法需要在PAL26中创建对来自多个.NET线程的请求进行排序的新线程66。换言之，.NET线程(例如，C#或Visual Basic中的应用程序线程)被映射到SYMBIAN中抢先调度的线程，并且其函数调用由附加PAL线程来排序。
现在，再次考虑图3中的示例，其中存在在其主循环中具有函数的两个.NET线程64，并且其请求由独立PAL线程66来排序。在这种情况下，无需为两个.NET线程创建抢先调度的线程。相反，因为其请求在PAL线程中排序并且因为SYMBIAN操作系统28提供有力支持的轻量线程模型，所以不同的任务可以在单个线程中执行。所以，如果应用程序线程的主函数满足特定需求，则无需为每个应用程序线程创建抢先调度的线程。
主要的要求是应用程序线程58的主函数调用在附加PAL线程66中排序的异步函数。大多数函数(例如，文件函数、联网函数、消息通信函数、以及甚至打印语句)满足该特性。结果，有可能所提议的优化可被应用于许多(如果不是大多数)应用程序线程。另一方面，要求虚拟执行系统20知道哪些托管函数被映射到底层操作系统28的异步函数调用以及哪些不是。该信息通过将合适的元数据嵌入托管代码库来变得可用。给定该信息，执行引擎24能够动态地决定其是否需要为应用程序线程创建新的抢先调度的线程或是否可以使用SYMBIAN的轻量线程模型。
另外参考图4，在所提议的优化中，可以使用SYMBIAN的轻量线程模型。基本上，SYMBIAN的轻量线程模型由以下两个核心组件构成：活动对象和活动调度器。活动对象68与活动调度器一起使应用程序员更容易处理协作多任务处理。通常，应用程序14包括存在于单个抢先调度的线程中的一组活动对象，即，使用协作多任务处理。
被表示为活动对象68的不同任务之间的控制转移如下发生。首先，如示例1中所讨论的，SYMBIAN操作系统28提供各种本地服务提供方，即所谓的服务器54。这些服务器支持异步函数请求。换言之，如果应用程序14调用异步函数，则该函数请求被发送至服务器，该服务器执行该函数请求，并且通知做出调用的应用程序该函数请求何时被执行。由于服务器存在于与应用程序不同的线程64或进程中，因此这意味着该应用程序在等待异步请求完成的同时具有一些空闲时间。实际上，每次应用程序调用异步函数时，使用此方法来在由活动对象抽象化的不同任务之间转移控制。
在各实施例中，如果满足上述要求，则使用该活动对象概念来表示虚拟执行系统20中的应用程序线程58。再一次，这些要求是重要的，因为在应用程序线程没有以规则的间隔调用异步函数的情况下该任务能够阻塞所有其他任务。然而，SYMBIAN操作系统28中的许多函数具有异步表示并且几乎所有PAL层函数(例如，文件函数、联网函数、打印语句和消息通信函数)都需要在PAL线程66中排序。
图4和图5分别提供了两个可能的体系结构70和72的图形概观。在图4中，只有应用程序线程58被表示为活动对象68，并且用于排序请求的数据结构依旧在那里。只要应用程序线程调用在PAL26中排序的函数，该请求就以异步方式实现。换言之，(1)该请求作为异步请求被转发到PAL线程66，(2)由于该请求是异步的，控制被自动转移到表示另一个应用程序线程的另一个活动对象，(3)该活动对象执行其指令直到它也达到异步函数调用，(4)在异步函数完成的情况下，标识发出相应的异步请求的活动对象，(5)原始活动对象检索先前的异步函数调用的结果并且执行进一步的指令，直到(6)它再次调用异步函数。在存在对于其先前的异步调用的结果可用的多个活动对象的情况下，SYMBIAN的活动调度器基于简单的优先级决定接下来激活哪个活动对象。
如果活动对象68可以在维护到不同的SYMBIAN服务器54的连接的相同的线程74中创建，则也可能消除附加PAL线程66。这是处理在示例1中讨论的SYMBIAN操作系统28的安全约束的另一个可能的方式。图5示出了相应的体系结构。
以下是从基于多个具体实验的所提议优化的评估中收集的数据，这些实验使用运行SYMBIAN操作系统28的设备12上的虚拟执行系统20来执行。这些实验在高端、启用SYMBIAN的智能电话上执行，该智能电话具有用于在其上执行的SYMBIAN的微软的CLR移植。
图6和7示出由附加PAL线程66引起的开销。具体地，图6是时间相对于使用SYMBIAN设备12的打印语句的重复次数的曲线图。图6中上方的轨迹76包括从不具有附加PAL线程的SYMBIAN设备中获取的数据，而下方的轨迹78包括从具有附加PAL线程的SYMBIAN设备中获取的数据。类似于图6，图7是时间相对于不如使用SYMBIAN设备的打印语句复杂的操作的重复次数的曲线图。图7中上方的轨迹80包括从不具有附加PAL线程的SYMBIAN设备中获取的数据，而下方的轨迹82包括从具有附加PAL线程的SYMBIAN设备中获取的数据。
可以看出，开销(即，分别在上方轨迹76和80与下方轨迹78和82之间的差别)取决于将要执行的操作的复杂度。例如，打印语句在SYMBIAN中是相当复杂的函数，因为打印语句经常需要刷新整个屏幕，这是由于字符串经常附连到控制台窗口的末尾。鉴于此，打印语句经常导致自动卷屏。执行不涉及卷屏的另一个函数，除去附加PAL线程66的优点甚至更加显而易见，如图7所示。在后一种情况下，附加PAL线程耗费执行该函数的整体性能中的大约20％。
抢先调度的线程64导致资源受限设备12上显著的性能损失这一事实也从以下实验的结果中得到支持。图8和图9示出了相对于应用程序线程58的数量仿真器(见轨迹84)和资源受限设备(见轨迹86)执行由PAL线程66排序的固定数量的PAL函数所需的时间。请注意，在仿真器上以及在实际资源受限设备上的所有线程执行了几乎相同数量的函数调用。例如，如果该实验由执行来自50个不同的应用程序线程的100,000个PAL函数调用组成，则底层操作系统28均等地分配这些调用以使得50个应用程序线程中的每一个发出这些调用中的大约2,000个。无需额外的显式同步。如从图8和9可以看出，线程数量的影响在仿真器上并没有很大的效果，但是实际资源受限设备上的线程数量的影响是显著的。
参考图10，最后一个实验处理操作系统28中托管线程的开销(见轨迹88)相对于纯线程的开销(见轨迹90)。执行与上述相同的实验，但是这次编写直接在资源受限设备12上执行的C#程序而不是使用非托管代码。先前实验中对非托管代码的使用对于评估底层操作系统的影响是有必要的。从图10可以看出，托管代码需要维护各种附加数据结构这一事实极大地影响性能。这使得更有必要应用所建议的优化技术以提高效率。
总之，以上实验结果支持所讨论的优化有可能极大地提高资源受限设备12上的虚拟执行系统20的效率这一思想。有利的是，这些优化增加了虚拟执行系统对托管函数、应用程序特有特性、底层设备的资源约束和操作系统28的特性之间的相互关系的认识。换言之，优化通过将关于这些调用在较低层(例如，操作系统层)上的效果的信息提供给虚拟执行系统中负责处理托管代码的较高层来促进。这通过用附加元数据来注释托管代码来完成，该附加元数据被虚拟执行系统用来执行优化，该优化将托管函数映射到平台自适应层26和操作系统层上合适的调用和数据结构。
有利的是，各实施例包括被配置成在资源受限设备12中使用并且在应用程序14的执行期间提供改进的虚拟执行系统20。该资源受限设备包括操作系统28和包括指令16的应用程序。该虚拟执行系统包括被配置成执行该应用程序的执行引擎24、以及被配置成将来自该执行引擎的调用映射到底层操作系统的PAL 26。相比于最初在台式系统上所预见的，资源受限设备的操作系统提供不同的能力并具有不同的限制。为了利用该附加能力并且有效地克服资源受限设备上的操作系统的限制，虚拟执行系统使用非功能方面。非功能方面表征应用程序指令并允许执行引擎和PAL利用底层操作系统的特性。执行引擎与PAL一起基于非功能方面在应用程序的执行期间实现改进。改进能够影响性能或存储器需求，以及诸如如非功能方面所表达的安全性或及时性等特性。
尽管用对结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为实现以下权利要求书的示例形式而公开的。此外，尽管术语“步骤”可在此处用于指示所采用的方法的不同方面，但该术语不应被解释为暗示此处所公开的各个步骤中或之间的任何特定次序，除非且当明确描述了各个步骤的次序的时候。