本文由中国C#技术学习中心整理 如果你对本文有不明之处请到技术论坛讨论!
第二章 理论基?糜镅?运行环境
既然你已经具有了C#全面的印象,我也想让你了解NGWS runtime的全貌.C#依靠由NGWS提供的运行时;因此,有必要知道运行时如何工作,以及它背后所蕴含的概念.
所以,这一章分为两部分——它们是所有的概念和使用的基? Ａ讲糠值哪谌菟淙挥行┲氐?但它有助于加深理解正在学习的概念.
2.1 NGWS Runtime
NGWS和NGWS Runtime为你提供了一种运行时环境.该运行时管理执行代码,并提供了使编程更容易的服务.只要你的编译器支持这种运行时,你就会从这种受管理的执行环境中得益.
你猜测C#编译器支持NGWS runtime很正确,但是不仅它支持NGWS runtime,VB和C++也支持.这些为支持运行时所创建的代码称作"受管代码"( managed code ).以下是你的应用程序从NGWS runtime那里所得到的利益：
交叉语言集成( 通过通用语言规范 )
自动内存管理( 垃圾收集 )
交叉语言异常处理( 统一展开 )
增强安全( 包括类型安全 )
版本支持( "DLL地狱"终结者 )
组件交互简化模式
因NGWS runtime 要提供了所有的这些好处,编译器必须把元文件和受管代码一起发出.元文件描述代码中的类型,它和你的代码存在一起( 与PE类似---PE为可变位执行文件 )
正如你从很多种交叉语言功能所看到的,NGWS runtime主要是关于高度集成交叉多异编程语言( tight integration across multiple different programming languages ).这种支持可达到允许你从一个VB对象派生出一个C#类的程度( 我后面会给出要讨论的文章 ).
C#程序员将会喜欢的一个功能是,他们不必担心内存管理—也就是说不必担心臭名昭著的内存泄漏.NGWS runtime提供了内存管理,当对象和变量的生命期结束( 不再被引用 )时,垃圾收集器释放它们.我真的喜欢这个功能,因为在COM中的内存管理一直是我的一块心? ?
应该鼓励配置一个管理应用程序或者组件.因为管理应用程序含有元数据文件,NGWS runtime可以利用这些信息,以确保你的应用程序具有它所需的各种规定版本.所产生的明显效果为,由于你的代码没有相互之间的依赖,很少可能出现中断.
这章余下来的将分为两部分,每一部分讨论NGWS runtime的各个方面,直到你的C#应用程序能执行为止.
1、中间语言( Intermediate Language,缩写IL )和元数据
2、即时编译器( 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 ),并使它连接每一个类型的方法.当一个方法第一次被调用时,存根把控制交给JIT.JIT把IL编译为原始代码,且把存根指针指向缓冲了的原始代码.接着的调用将执行原始码.在某些位置上( At some point ),所有的IL都被转换成为原始代码,而JITter处于空闲状态.
正如我在前面提到的,JIT编译器有很多,不止一个.在Windows平台上,NGWS runtime装有3个不同的JIT编译器.
JIT——这是NGWS runtime默认使用的JIT编译器.它是一个后台( back end )优化的编译器 ,在前台( up front )实行数据流分析,并创建了高度优化的受管原始代码做为输出结果.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目录中.
尽管它是一个小小的对话框,可是你所选择的选项功能是相当强大的.每一个选项将在以下描述.
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类型系统所定义的类型.元数据的永久格式与编程语言无关,但是,元数据拿自己当作一种互换机制( nterchange mechanism )来使用,这种互换是在在工具和NGWS的虚拟执行系统之间.
本文由中国C#技术学习中心整理 如果你对本文有不明之处请到技术论坛讨论!
|
