CSDN博客

img rainbow

<<展现C#>> 第二章 NGWS Runtime 技术基础(修订)

发表于2000/8/14 8:13:00  1485人阅读

 

 

                 第二章  NGWS  runtime 技术基础

 

    既然你已经具有了C#全面的印象,我也想让你领略NGWS runtime的全貌。C#依靠由NGWS提供的运行时;因此,有必要知道运行时如何工作,以及它背后所蕴含的概念。

    所以,这一章分为两部分——它们是所有的概念和应用的基础。两部分的内容虽然有些重叠,但有助于加深理解正在学习的内容。

 

2.1  NGWS  Runtime

    NGWSNGWS Runtime为你提供了一种运行时环境。该运行时管理执行代码,并提供了使编程更容易的服务。只要你的编译器支持这种运行时,你就会从这种受管理的执行环境中得益。

    你猜测C#编译器支持NGWS runtime很正确,但是不仅它支持NGWS runtimeVBC++也支持。这些为支持运行时所创建的代码称作“受管代码”(managed code)。以下是你的应用程序从NGWS runtime那里所得到的利益:

 

    ·跨语言平台集成(通过通用语言规范)

    ·自动内存管理(垃圾收集)

    ·跨语言平台异常处理(统一展开)

    ·增强安全(包括类型安全)

    ·版本支持("DLL地狱"终结者)

    ·组件交互简化模式

 

    NGWS runtime提供了所有的这些益处,编译器必须把元文件和受管代码一起发出。元文件描述代码中的类型,它和你的代码存在一起(PE类似---PE为可变位执行文件)

    正如你从很多种跨语言平台功能所看到的,NGWS runtime主要是一种高度集成的、跨越多种不同语言的平台。这种支持甚至允许你从一个VB对象派生出一个C#(我后面会给出要讨论的文章)

    C#程序员将会喜欢的一个功能是,他们不必担心内存管理——也就是说不必担心臭名昭著的内存泄漏。NGWS  runtime提供了内存管理,当对象和变量的生命期结束(不再被引用)时,垃圾收集器释放它们。我真的喜欢这个功能,因为在COM中的内存管理一直是我的一块心病。

    应该鼓励配置一个管理应用程序或者组件。因为管理应用程序含有元数据文件,NGWS runtime可以利用这些信息,以确保你的应用程序具有它所需的各种规定版本。所产生的明显效果为,由于你的代码没有相互之间的依赖,可能很少出现中断。

    这章余下的部份分为两小节,每一小节讨论NGWS runtime的各个方面,直到你的C#应用程序能执行为止。

        ·中间语言(Intermediate Language,缩写IL)和元数据

        ·即时编译器(just-in-time compliers,简称JITers)

 

2.1.1  中间语言和元数据

    C#编译器生成的受管代码并不是原始代码,但它是中间语言(IL)代码。这种IL代码自身变成了NGWS runtime的受管执行进程的入口。IL代码明显的优势在于它是CPU无关的,这也意味着,你要用目标机器上的一个编译器才能把IL代码转换成原始代码。

    尽管IL代码由编译器产生,但它并不是编译器提供给运行时仅有的东西。编译器同样产生代码的元数据,它告诉运行时有关代码的更多的东西,例如各种类型的定义、各种类型成员的名字以及其它数据。基本上,元数据是类型库、注册表内容和其它用于COM的信息。尽管如此,元数据还是直接和执行代码合并在一起,并没有分开。

    IL和元数据存放于扩展了PE格式的文件中(PE格式用于.exe.dll文件)。当这样的一个PE文件被装载时,运行时从文件中定位和分离出元数据和IL

    现在,我给出了已有的IL指令的简短目录。尽管它不是一个完整的清单,也不需要你熟记和理解,但是它为你提供了C#编程所必须具有的基础知识。

 

    ·算术和逻辑操作符

    ·控制流程

    ·直接内存访问

    ·堆栈操作

    ·参数和局部变量

    ·堆栈分配

    ·对象模式

    ·实例类型值

    ·临界区

    ·数组

    ·类型位置

    ·即时编译器(JITters)

 

2.1.2  即时编译器(JITters)

    C#或其它能产生受管代码的编译器所生成的受管代码就是IL码。虽然IL代码被包装在一个有效的PE文件中,但是你还是不能执行它,除非它被转换成为受管原始代码。这就是NGWS runtime 即时编译器(也称作JITters)大显身手的时候。

    为什么你会对即时编译代码感到厌繁, 为什么不把整个IL PE文件编译成原始代码? 答案是时间——需要把IL代码编译成CPU规格的代码的时间。这种编译将更加有效率,因为一些程序段从来就没有被执行过。例如,在我的字处理器中,邮件合并功能从来就没有被编译。

    从技术上说,全部的处理过程如下:当一个类型被装载时,装载器创建一个存根(stub),并使它连接每一个类型的方法。当一个方法第一次被调用时,存根把控制交给JITJITIL编译为原始代码,且把存根指针指向装入缓冲区的原始代码。接着的调用将要执行的原始码。在某些位置上,所有的IL都被转换成为原始代码,这时JITter处于空闲状态。

    正如我在前面提到的,JIT编译器有很多,不止一个。在Windows平台上,NGWS runtime带有3个不同的JIT编译器。

    JIT——这是NGWS runtime默认使用的JIT编译器。它是一个后台优化的编译器 ,在前台实行数据流分析,并创建了高度优化的受管原始代码作为输出结果。JIT可以使用不严格的IL指令集编码,但是所需资源将十分可观。主要的限制在于内存足迹(footprint)、结果工作集,以及实行优化所消耗的时间。

    EconoJIT—— 和主JIT相比,EconJIT的目标是把IL高速地转换成受管原始代码。它允许把产生的原始代码装入缓冲区,但是输出码并不象主JIT生成的代码那样优化(代码小)。当内存紧张时,快速代码生成方案的优势将荡然无存。永久地丢弃无用的、已JIT过的代码,就可以把更大的IL程序装入代码缓冲区。因为JIT编译快,执行速度也仍然很快。

    PreJIT——尽管它依据主JIT,但操作起来更象是一个传统的编译器。你安装了NGWS组件,它才能运行,才可以把IL代码编译成受管原始代码。当然最终的结果为,更快的装载时间和更快的应用程序启动时间(不需要更多的JIT编译)

在所列出的JITters中,有两个是运行时的JITters。可是你怎么决定要使用哪一个JIT,它如何使用内存? 有一个称为“JIT编译管理器”的小应用程序(jitman.exe),它存放在NGWS SDK安装目录下的bin目录中。当执行该程序时,它把一个图标加到系统任务条上,双击该图标打开程序对话框(见图2.1)

 

        2.1 JIT编译管理器允许你设置各种相关性能的选项

 

    尽管它是一个小小的对话框,可是你所选择的选项功能是相当强大的。每一个选项将在以下描述。

    Use EconoJIT only 选项——当该复选框没有选上时,NGWS runtime使用默认的正常的JIT编译器。前面就曾经解释过两种JITter的区别。

    Max Code Pitch Overhead(%)选项——该设置仅保留给EconoJIT。它控制了JIT编译时间和执行代码时间的百分比。如果超过了设定的值,代码缓冲区得到扩充,以缩短JIT编译所消耗的时间。

    Limit Size of Code Cache选项——该项默认为没有选中。没有选择该项意味着缓冲区将利用它所能得到的内存。如果你想限制缓冲区大小,选中该选项,这将允许你使用Max Size of Cache(bytes)选项。

    Max  Size  of  Cache(bytes)选项—控制容纳JIT代码的缓冲区的最大值。虽然你可以非常严格地限制这个值,但你还是应该小心,不能超过这个缓冲区所适合的最大值。否则该方法的JIT编译将会失败。

    Optimize For Size选项——告诉JIT 编译器,优化的目的是为了使代码更小而不是能执行得更快。这个设置默认是关掉的。

    Enable Concurrent GC[garbage collection]选项——垃圾收集(GC)默认地运行在用户代码的线程中。意味GC发生时,可能会注意到回应有轻微的延迟。为防止出现该现象,打开当前GC。注意,当前GC比标准GC更慢,它仅在windows 2000上写时(the time of writing)有效。

    当用C#创建项目时,你可能使用不同的设置试验过。当创建 UI-intensive应用程序时,你将会看到允许当前GC的最大差别。

 

2.2 虚拟对象系统(VOS)

    到目前为止,你仅看到了NGWS runtime如何工作,但是并不了解它工作的技术背景以及为什么它要这样工作。这节都是关于 NGWS 虚拟对象系统的(VOS)

    以下为在VOS中形成声明、使用和管理类型模型时,NGWS runtime的规则。在VOS背后的思想是建立一个框架,在执行代码时不能牺牲性能,允许跨平台语言集成和类型安全。

    我提到的框架是运行时架构的基础。为了帮助你更好地了解它,我将它勾划出四个区域。当开发C#应用程序和组件时,理解它们很重要。

    VOS类型系统——提供丰富的类型系统,它打算支持全面编程语言的完全实施。

    元数据——描述和引用VOS类型系统所定义的类型。元数据的永久格式与编程语言无关,但是,元数据把自己当作一种互换机制来使用,这种互换处于工具和NGWS的虚拟执行系统之间。

    通用语言规范(CLS)——CLS定义了VOS中类型的子集,也定义了常规的用法。如果一个类库遵守CLS的规则,它确保类库可以在其它所有能实现CLS的编程语言上使用。

    虚拟执行系统(VES)——这是VOS实时的实现。VES负责装入和执行为NGWS运得时编写的程序。

    这四个部分一起组成了NGWS runtime架构。每一部分在下面小节中描述。

 

2.2.1 VOS类型系统

    VOS类型系统提供丰富的类型系统,它打算支持多种编程语言的完全实施。所以,VOS必须都支持面向对象的语言和过程编程语言。

    现在,存在着很多种近似但有点不兼容的类型。就拿整型当例子,在VB中,它是16位长,而在C++中,它是32位。还有更多的例子,特别是用在日期和时间以及数据库方面的数据类型。这种不兼容使应用程序的创建和维护不必要地复杂化,尤其当程序使用了多种编程语言时。

    另一个问题是,因为编程语言之间存在着一些差别,你不能在一种语言中重用另一种语言创建的类型。(COM用二进制标准接口部分地解决了这个问题) 当今代码重用肯定是有限的。

    发布应用程序的最大障碍是各种编程语言的对象模型不统一。几乎每一方面都存在着差异:事件、属性、永久保存等等。

    VOS这里将改变这种现象  VOS定义了描述值的类型,并规定了类型的所有值所必须支持的一条合约。前面提到的支持面向对象和过程编程语言,就存在着两种值和对象。

 

    对于值,类型存储于表述中,同样操作也在其中实行。对象更强大因为它显式地存于表述中。每一个对象都有一个区别于其它对象的识别号。支持不同的VOS类型在第四章 C#类型”中提出。

 

 

2.2.2元数据

    尽管元数据用于描述和引用由VOS类型系统定义的类型,但它还不能锁定到这个单个目标。当你写一个程序时,通过利用类型声明,你所声明的类型(假定它们是数值类型或引用类型)被介绍给NGWS runtime类型系统。类型声明在存于PE可执行文件内部的元数据中得到描述。

    基本上,元数据用于各项任务:用来表示NGWS runtime用途的信息,如定位和装载类、  内存中这些类的事例、解决调用 、翻译IL为原始码、加强安全并设置运行时上下文边界。

    你不必关心元数据的生成。元数据是由C#的“代码转IL编译器”(code-to-IL compiler,不是JIT编译器)生成的。代码转IL编译器发送二进制元数据信息给PE文件,是以标准的方式发送的,不象C++编译器那样,为出口函数创建它们自己的修饰名字。

    你从元数据和可执行代码并存所获得的主要优势为,有关类型的信息同类型自身固定在一起,不会遍布很多地方。同样有助于解决存在于COM中的版本问题。进一步地,你可以在相同的上下文中使用不同的版本库,因为库不仅被注册表引用,也被包含在可执行代码中的元数据引用。

 

 

2.2.3通用语言规范

    通用语言规范(CLS)并不是虚拟对象系统(VOS)真正的一部分,它是特殊的。CLS定义了VOS中的一个类型子集,也定义了必须符合CLS的常规用法。

    那么,对此有什么迷惑呢?如果一个类库遵守CLS规则,其它编程语言同样也遵守CLS规则,那么其它编程语言的客户也可以使用类库。CLS是关于语言的交互可操作性(interoperability)。因此,常规用法必须仅遵循外部可访问项目 (externally visible  items)如方法、属性和事件等等。

    我所描述的优点是你可以做以下工作。用C#写一个组件,在VB中派生它,因加在VB中的功能是如此之强大,在C#中再次从VB类派生它。只要所有的外部可访问项遵守CLS规则,这样是可行的。

    我在这本书中出示的代码不关心CLS协定。但在构建你的类库时要注意到CLS协定。我提供了表2.1,用以给类型和外部可访问项定义协定规则。

    这个清单不完整。它仅包含一些很重要的项目。我不指出出现在本书中每一种类型的CLS协定,所以有个好主意:当你寻找CLS协定时,至少应该浏览该表,以了解哪种功能有效。不要担心你不熟悉这张表中的每一个含义,在这本书中你会学到它们。

 

                        2.1   通能语言规范中的类型和功能

 

     ·bool

     ·char

     ·byte

     ·short

     ·int

     ·long

     ·float

     ·double

     ·string

     ·object(所有对象之母)

   

     Arrays(数组)

     数组的维数必须是已知的(>=1),而且最小下标数必须为0

     元素类型必须是一个CLS类型。

 

     类型(Types)

     可以被抽象或隐藏。

     零或更多的接口可以被实现。不同的接口允许拥有具有相同名字和签名的方法。

     一个类型可以准确地从一个类型派生。允许成员被覆盖和被隐藏。

     可以有零或更多的成员,它们是域成员、方法、事件或者类型。

     类型可以拥有零或更多个构造函数。

     一种类型的可访问性可以是公共的或者对NGWS组件来说是局部的;但是,只有公共成员可以认为是类型接口的一部分。

     所有的值型必须从系统值型继承。异常是一个枚举——它必须从系统枚举(System Enum)继承。

                      

     类型成员

     类型成员允许隐藏或者覆盖另一种类型中的其它成员。

     参数和返回值的类型都必须是 CLS 协定类型。

     构造函数、方法和属性可以被重载。

     一个类型可以有抽象成员,但仅当类型不被封装时。

 

     方法

     一种方法可以是静态、虚拟或者实例。

     虚拟和实例方法可以是抽象的,或者是一个实现。静态方法必须总拥有一个实现。

     虚拟方法可能是最后的(或者不是)

 

     域成员

     可以是静态或者是非静态。

     静态域成员可以被描述或只初始化。

 

     属性

     当获取和设置方法而不是使用属性语法时,属性可以公开。

     获取的返回类型和设置方法的第一个参数必须是相同的CLS类型——属性的类型。

     属性名字必须不同,不同的属性类型用于区分是不充分的。

     由于使用方法实现属性访问,如果 PropertyName 是同一个类中定义的一个属性,你不能实现命名为 get_PropertyName set_PropertyName 的方法。

     属性可以被索引。

     属性访问必须遵循这种命名格式:get_ProNameset_PropName

 

     枚举

     强调类型必须是byteshortint long

     每一个成员是一个枚举类型的静态描述域成员

     一个枚举不能实现任何接口。

     你允许给多个域成员设定相同的值。

     一个枚举必须继承系统枚举(隐含在C#)      

 

     异常

     可以被引发和被捕获。

     自定义异常必须继承系统异常。

 

     接口

     可需要实现其它接口。

     一个接口可以定义属性、事件和虚拟方法。实现取决于派生类。

    

     事件

     要么都进行增加方法和取消方法,要么都不进行。每一种方法采用一个参数,它是从系统代表元(System Delegate)派生下来的一个类。

 

     自定义属性

     可以仅使用下列类型:Type(类型),char, char, bool, byte, short, int, long, float, double, enum (一种CLS 类型), and object.

 

     代表元(Delegates)

     可以被创建和被激活

 

     标识符(Identifiers)

     一个标识符的第一个字母必须来自一限制集。

     通过大小写在单一范围内,不可能唯一地区别两个或更多个标识符(大小写不敏感)

 

2.2.4虚拟执行系统(VES)

     虚拟执行系统实现了虚拟对象系统。通过实现一个负责NGWS runtime的执行引擎(execution engine,缩写EE)创建VES。这个执行引擎执行由C#编写和编译的应用程序。

     下列组件为VES的一部分。

     1、中间语言(IL)——被设计为很容易被各种各样的编译器所兼容 。在该框架之外,C++VBC#编译器都能够生成IL

     2、装入受管代码——包括解决内存中的名字、 表层类,并且创建JIT编译所必需的存根。通过执行经常性校验,包括加强一些访问规则,类装载器同样也增强了安全性。

     3、用JIT转换IL成原始代码——IL代码并不是设计成为一种传统的解释字节代码或树型代码,IL转换是真正的编译。

     4、装入元数据、校验类型安全和方法的完整性

     5、垃圾收集(GC)和异常处理——两者都是基于堆栈格式的服务。受管代码允许你动态地跟踪堆栈。要动态地识别各个堆栈框架,JITter或其它编译器必须提供一个代码管理器。

     6、描绘和查错服务——两者都取决于由源语言编译器所生成的信息。必须发出两个映射:一个映射从源语言结构发到指令流中的地址,一个映射从地址发到堆栈框架中的位置。当执行从IL到原始代码的转换时,这些映射被重新计算。

     7、管理线程和上下文,还有远程管理——VES为受管代码提供这些服务。

     虽然这个清单并不完整,但它足以让你理解运行时基于的由VES提供的低层架构。肯定将会有专门讨论运行时的书,而这本书只稍为深入地挖掘各种话题。

 

2.3 小结

     这一章,我带你到运行时的世界一游。描述了当创建、编译和配置C#程序时它是如何工作的。你学会了中间语言(IL),还有元数据是如何用于描述被编译为IL的类型。元数据和IL都用于JITter检测和执行代码。你甚至可以选择用哪一种JITter来执行应用程序。

     在这一章的第二部分,涉及到了运行时为何按这种方式工作的理论。你学到了虚拟对象系统(VOS)以及组成它的那部分。对于类库设计者,他们最为感兴趣的就是通用语言规范(CLS),它为基于VOS的语言协同工作设定规则。最后,你看到了虚拟执行系统(VES)如何通过NGWS runtime实现VOS

 

0 0

我的热门文章

相关博文

img
取 消
img即使是一小步
也想与你分享
打开
img