原文地址:http://blog.csdn.net/ariesjzj/article/details/9292467
长期以来.NET框架都被认为是Windows下的专利,而Mono可以让.NET程序跑在其它的平台(如Linux, OS X等)上。近几年由于移动设备的兴起,Mono的衍生项目(MonoTouch和Mono for Android)还可以让基于.NET框架的程序轻易的移植到Android和iOS设备上,这让原本Windows上的C#程序员上手移动开发的周期大大缩短。
Mono主要包含了C#的编译器,CLI(Common Language Infrastructure)实现和一系统相关开发工具。本文将简要介绍Mono的安装,主要组件和大体工作流程。一、 源码下载,编译,安装
要是怕麻烦的话,Ubuntu上有现成的安装包:
# apt-get install mono-runtime
其实源码安装也需要系统上已有C#编译器,所以至少得先装:
# apt-get install mono-gmcs
下载源码:
$ git clone https://github.com/mono/mono.git
然后checkout出想要的版本,这步可选。这里我checkout出了2.10版,因为传说最新monodroid用的就是这个版本
$ git checkout remotes/origin/mono-2-10
接着按README上的方法编译安装:
$ ./configure --prefix=/usr/local
$ make
$ make install
然后就可以用了,mono/mono/tests下有很多例子,随便拿一个试试:
$ mcs threadpool.cs
$ /usr/local/bin/mono threadpool.exe
二、源码结构
这里仅列举几个重要的目录:
mcs:
mcs: Mono实现的基于Ecma标准的C#编译器。
class: CLI的C#级的实现。类似于Android中的Java层,应用程序看到的是这一层提供的接口。这一层是平台无关的。
ilasm: 反汇编器,将Native code反汇编成bytecode。
mono:
mini: JIT编译器,将bytecode编译成native code。
metadata: Mono的runtime,CLI的Native级的实现。
io-layer: 与操作系统相关的接口实现,像socket,thread,mutex这些。
libgc: GC实现的一部分。
三、Mono主要工作框架
mini/main.c: main()
mono_main_with_options()
mono_main()
mini_init()
mono_assembly_open()
main_thread_handler() // assembly(也就是bytecode)的编译执行
mini_cleanup()
main_thread_handler()
mono_jit_exec()
mono_assembly_get_image() // 得到image信息,如"test.exe"
mono_image_get_entry_point() // 得到类,方法信息
mono_runtime_run_main(method, argc, argv, NULL)
mono_thread_set_main(mono_thread_current()) // 将当前线程设为主线程
mono_assembly_set_main()
mono_runtime_exec_main() // 编译及调用目标方法
mono_runtime_exec_main()
mono_runtime_invoke(method, NULL, pa, exc) // 要调用的方法,如"ClassName::Main()"
default_mono_runtime_invoke() // 实际上是调用了mono_jit_runtime_invoke()
info->compiled_method = mono_jit_compile_method_with_opt(method) // 编译目标函数
info->runtime_invoke = mono_jit_compile_method() // 编译目标函数的runtime wrapper
mono_jit_compile_method_with_opt(method, default_opt, &ex)
runtime_invoke = info->runtime_invoke
runtime_invoke(obj, params, exc, info->compiled_method) // 调用wrapper,wrapper会调用目标方法
mono_jit_compile_method_with_opt()
mono_jit_compile_method_inner()
mini_method_compile(method, opt, target_domain, TRUE, FALSE, 0) // 通过JIT编译给定方法
mono_runtime_class_init_full() // 初始化方法所在对象
method = mono_class_get_cctor() // 得到类的构造函数
if (do_initialization) // 对象需要初始化
mono_runtime_invoke() // 调用相应构造函数来构造对象,如"System.console:.cctor()"
mono_jit_runtime_invoke()
四、垃圾回收
垃圾回收(GC)是CLI中很重要的部分,针对这部分的开发仍然很活跃。现在默认的GC实现称为SGen(Simple Generational),除此之外的选择还有Boehm(http://jezng.com/2012/02/How-the-Boehm-Garbage-Collector-Works/),Boehm GC的基本思想是在malloc()时记录分配空间的元信息,然后在数据中保守地检查每个可能为指针的整数。其好处是只要截malloc()和free()两个接口即可,因此可被用于uncooperative环境(即C/C++这种指针和整数界限模糊的情况),缺点是由于做法保守可能会有垃圾无法被回收。另外Boehm中对象不能被移动,所以会有fragmentation。SGen的主要思想是将对象分为两个generation:较新的称为generation 0,较老的称为generation 1。这种设计是基于这样的一个事实:程序经常会申请一些小的临时对象,用完了马上就释放。而那些一段时间没释放的,往往很长时间都不会释放,如全局对象等。基于这个原则,SGen将GC分两个阶段:minor collection和major collection,分别用于回收nursery heap和major heap中的内存。
* Minor collection(generation 0):又称为nursery collection,用来回收nursery heap(默认为4M)。采用的是copying collection。默认情况下,系统在启动时就申请了一块4M的连续内存,然后应用程序申请内存就从中申请,如果不够了就触发minor collection。发生minor collection时,第一步是找到哪些对象是还被引用的,那剩下的自然就是可以回收的“垃圾”了。如何找到那些还“活”着的对象呢?对象的引用关系可以抽象成一个图(准确地说是个“森林”)。首先是从一些特定对象(称为root)开始,找出它们引用的对象,然后继续找出这些这些被引用对象所引用的对象,以此类推,直到没有需要被遍历的对象为止。那么这些特定对象是什么呢?它们主要包含了静态成员引用,CPU寄存器,线程栈上的对象和runtime本身所引用的对象等。由于默认GC发生时是要"stop the world"的,因此CPU 寄存器会被压入栈中,这些寄存器中可能会有对对象的引用,这又衍生出两种对栈的扫描方法-conservative scan和precise scan。所谓conservative scan就是保守地把栈中的每个指针大小的值都认为是指针,一旦指向某个对象,那么那个对象就被认为是还活着的。precise scan中,寄存器中的对象引用和它们在栈上的位置都被记录下来,这样GC时就可以有的放矢了。扯远了,那么将这些对象标记完了之后做什么呢?对于被引用的对象,也就是”活”着的对象,它们被光荣地“升级”到genearation 1了。所谓的升级就是将这个对象从nursery heap拷到major heap。与此同时,引用它的对象也都得相应更新。Mono用了个trick,就是借用了对象起始处的虚函数表指针的后两位(因为虚函数表地址4 byte对齐,所以末两位必为0)的一位作为forwarding pointer(SGEN_OBJECT_IS_FORWARDED)的标志,即如果被置位,则该虚函数表指针指向的就不是虚函数表了,而是该对象在major heap中的新位置。其实有点想不通是,这样forwarding pointer自身还是在nursery heap中,时间长了不是也会引起fragmentation么。* Major collection(generation 1):回收major heap(这个大小可以是固定的也可以是动态分配的,固定的话默认为512M)。 这一阶段有几种实现-'marksweep','marksweep-fixed','marksweep-fixed-par'和'copying' 。mark&sweep是默认的实现。所谓mark&sweep,就是先mark然后sweep(废话)。mark阶段和minor collection无异。即从一些root对象开始,遍历所有它们引用的对象并且置标志位。完了以后,sweep阶段会线性扫描这些对象,将没有标志位的对象释放。如果这样就结束了,那自然会出现fragmentation的问题。所以实际上,当mark&sweep结束后,系统会检查每个块(major heap中的空间被分成固定大小的块)的碎片率,如果高于一定阀值,则标志该块以待copy压缩(实现在ms_sweep()中)。这种方案既不是每次GC时都去除全部fragmentation,也不是放任不管。可以看到,现实当中,好的设计往往需要折衷。
因为默认情况下GC发生时需要挂起其余进程,所以如果GC时间太长了就很影响用户体验。从上面的实现可以看出,nursery collection是轻量级的,很快就能完成,因此发生的频率也会高些,而major collection会慢得多,因此发生频率会低很多。当然,这都是针对被动调用GC而言的,也就是当申请对象内存不足时调用GC。除此之外,用户可以通过调用GC.Collect()或GC.Collect(GC.MaxGeneration)函数主动触发GC。
Mono中对GC的实现主要分为下面几步:
1. 初始化
mono_gc_init()
mono_gc_base_init()
mono_sgen_marksweep_init() // 设置major_collector里的一坨函数
alloc_nursery() // 分配nursery heap
mono_gc_init_finalizer_thread() // 起"Finalizer"线程,用来执行对象的Finalizer方法
finalizer_thread()
WaitForSingleObjectEx() // 阻塞住,等待finalizer_event
...
2. 申请内存,如
mono_object_allocate()
ALLOC_OBJECT()
mono_gc_alloc_obj()
mono_gc_alloc_obj_nolock()
mono_gc_alloc_obj_nolock()
if (size > MAX_SMALL_OBJ_SIZE) { // 大对象,直接从OS申请
mono_sgen_los_alloc_large_inner()
} else {
p = (void **)TLAB_NEXT; //尝试从TLAB中申请, TLAB(thread local allocation buffer)是为了避免原子操作损耗而为每个线程从nursery heap中预先分配的线程私有缓存,默认为4K
if (new_next < TLAB_TEMP_END) { // 从TLAB申请成功
return p;
}
if (TLAB_NEXT >= TLAB_REAL_END) { // TLAB分配不了
if (size > tlab_size) { // 要分配的空间比整个TLAB还大,只能nursery heap里分配了
if (!search_fragment_for_size(size))
minor_collect_or_expand_inner(size) // 空间不够,调用GC
p = (void *)nursery_next; //从nursery heap中分配
nursery_next += size
} else { // 要分配的空间比TLAB最大容量小,TLAB虽分配失败但有希望分配
if (alloc_size >= available_in_nursery) {// nursery heap中空间不够分配TLAB的
minor_collect_or_expand_inner(tlab_size) // 调用GC,整出TLAB大小的nursery heap空间
}
// 从nursry heap中分配TLAB
TLAB_START = nursery_next;
...
// 再从TLAB分配空间
p = (void *)TLAB_NEXT;
}
}
return p;
}
3. 接下来就是高潮(GC)了:) 大概框架是先看看nursery collection能不能搞定,不行就换猛料major collection。
minor_collect_or_expand_inner()stop_world(0) // stop the world
if (collect_nursery()) {
major_collect() // minor collection不给力
major_do_collection()
}
restart_world(0) // 将其它线程唤醒, Finalizer线程随之开始工作
Minor collection主要流程:
collect_nursery()
gray_object_queue_init() // 广度优先遍历时需要用的列队
// 从各种root开始广度优先遍历,所到之处就copy到major heap,然后压队列
pin_from_roots()
scan_from_remsets()
if (use_cardtable)
scan_from_card_tables()
scan_from_registered_roots()
scan_from_registered_roots()
finish_gray_stack()
finalize_in_range() // 将finalization queue里的对象也作为root
queue_finalization_entry() // 将“死”对象加入finalization queue,以待销毁
build_nursery_fragments() // 建立起free list(nursery_fragments)以备下次申请内存时使用
if (fin_ready_list || critical_fin_list)
mono_gc_finalize_notify() //发信号给Finalizer线程,让阻塞等待信号的Finalizer线程开始工作
// 看看nursery collection完了以后是不是满足内存申请需求
need_major = need_major_collection(0) || objects_pinned
return need_major;
major collection和minor collection做的事情类似,各种scan函数用的也是同一个,只是copy这个函数的行为不一样了,这通过将copy函数作为参数t加以区分(major_collector.copy_object和major_collector.copy_or_mark_object)来实现。
major_do_collection()
// 和minor collection类似,root集合出发,广度优先遍历,标记“活”对象。这步即为mark阶段。
...
major_collector.sweep() // 这步为sweep阶段
4. finalizer_thread() // 初始化时是被阻塞起来等待事件的,上面collection完了发事件后该线程会继续执行
mono_gc_invoke_finalizers()
while (fin_ready_list || critical_fin_list) { // finalization queue有对象要处理
finalize_entry_set_object()
mono_gc_run_finalize()
runtime_invoke() // 调用对象的Finalize()方法
}
上面的GC实现看起来似乎已经简单而华丽地解决了垃圾回收问题,但现实往往不会这般完美,总会有些不尽如人意的方面需要解决,如下面几点:
* Finalization:我们知道,C#中的Finalizer()方法(CLI生成,用户只能提供析构函数)用于销毁对象。Finalizer方法会调用析构函数,析构函数一般又会调Dispose函数。Dispose函数销毁对象中的unmanaged对象(如文件句柄,窗口句柄,socket连接或数据库连接等)。假设某类没有定义自己的Finalizer,那很好,GC在nursery collection阶段发现该对象没有被引用就可回收它。但如果不是这样,就麻烦得多了。GC会将该对象放到finalization queue里等待其Finalizer被调用。因为finalization queue里的对象还未被真正回收,因此它们此刻还是“活”的,因此它们会被升级成generation 1而且放到major heap,同时它们也作为下次collection时root的一部分。这个队列里的东西不是马上处理的,而是在单独的Finalizer线程(源码中为gc_thread,执行的线程函数为finalizer_thread())里处理的,所以放在这个队列里面的对象命运有两种:一种是处理的时候又被引用了,于是它们又“复活”(Resurrection)了。另一种就是还是没被引用,于是对象的Finalizer方法被执行,对象被销毁并标志清除。可以看到,有Finalizer的对象生命周期变长了,这会影响内存使用效率,另外Finalizer什么时候被调用难以控制,两个对象的Finalizer方法的执行顺序也难以保证,所以很多地方都建议能不要用Finalizer就不要用。那如果对象中有unmanaged对象咋办?有一个办法是写Dispose函数然后用完对象后手动调用,接着调用System.GC.SuppressFinalize (this),这样该对象就不会到finalization queue里去了。
Mono中Finalization的流程大体是:
mono_object_new_alloc_specific() // 对象在创建时就注册Finalizer
if (vtable->klass->has_finalize) // 对象是否有Finalizer
mono_object_register_finalizer() // 注册
...
register_for_finalization() //将该对象的Finalizer放到全局哈希表中(minor_finalizable_hash或major_finalizable_hash)
GC发生时会将上面哈希表对象中“死”的那些放到finalization queue中:
finalize_in_range()
if (object is dead)
queue_finalization_entry() // 将对象放到finalization queue(critical_fin_list或fin_ready_list)中
GC末期会发事件给Finalizer线程让其处理finalization queue上的对象。
* Pinned object
pin住的对象,可以简单地理解为位置不能移动的对象。那么什么情况下会产生这种对象呢?一种是C#程序员显式标为fixed(fixed Statement: http://msdn.microsoft.com/en-us/library/f58wzh21%28v=vs.80%29.aspx)的对象,另一种是当对象传给unmanaged code时,因为Mono无法预测unmanaged code会对该对象作何种引用,因此不能轻易移动对象位置。对这类顽固派对象只能让它们pin在那,然后烧高香下次GC之前它们已经被unpin了-_-
* 大对象(Large object)
SGen中把超过8K bytes(SGEN_MAX_SMALL_OBJ_SIZE)的对象作为large object。这些对象就不走前面说的nursery和major heap了,而是直接从OS申请,用完后释放回OS了。实现参见mono_sgen_los_alloc_large_inner()。
* Write barrier
首先,这和编译器优化中的write barrier指令没有半毛钱关系。这个名字非常confusing的东西是为了解决GC中的一个问题:即major heap中的对象A引用nursery heap中的对象B咋办?这个引用可能在A刚被整到major heap时还木有,是后来才有的。因为如果当时就有,那么对象B也会被整到major heap中,也就没这个问题了。那要解决这个问题,很自然地想到,得在major heap中对象A引用nursery heap中对象B时,记录这种行为,日后GC才可以用这个信息保证nursery heap中的对象不会被误删。
Mono中提供了两种解决方案:Cardtable和Remset,目前默认采用Cardtable。首先介绍Remset,其工作原理很简单,当上面所说这种情况发生时,将这种新加的引用记录在全局的RememberedSet中,在GC时,将这集合中的元素也作为root的一部分即可。Cardtable更加粗粒度,它把major heap分为固定大小的块(SGen中定为512 bytes,分块的好处是我们能用bitmap记录其状态),称为card,然后只记录该card中是否有对象引用了nursery,有则置上标记位。这样的好处是提高了效率,坏处是不能准确地知道是哪个对象引用了nursery heap中的对象。接下来的故事和Remset差不多,nursery collection发生时,扫描这些有标记位的块,将它们引用的nursery heap中的对象移到major heap中(即generation 0升级到generation 1),然后将所有标志位清零,以备下一次使用。这种设计再一次体现了“好的设计需要折衷”这句老话。
* 并行优化
默认GC需要挂起除自己外的线程,直到整个GC过程结束。如果垃圾甚多,则会影响用户体验。如何尽可能减小其影响呢?我们知道major collection主要分为两个过程Mark和Sweep。Mono中分别对其进行了优化:一个是parallel Mark,另一个是concurrent Sweep。前者是基于每个线程的root都包含了TLS的对象,因此可以并发遍历扫描,对于那些共享的对象,只要有一个线程mark它,那就mark它。后者是基于mark完了之后,那些“垃圾”对象就被置上位,不会被使用了,那么sweep这个过程就可以和应用程序一起执行,互不干扰了。
五、托管代码和非托管代码的相互调用
在CLI之上的如C#的产生的bytecode(CLI code)我们称之为managed code,是由虚拟机的JIT编译执行的,其中的对象无需手动释放,由GC管理。而C/C++写的以binary形式存在的code称为unmanaged code,其中的对象虚拟机无法track。这就像Android中的Java和Native code的区别。Java的bytecode跑在dalvik虚拟机上,而Native的code而直接跑在bare metal上。为了访问底层资源,Java中的接口很多最终还是要通过JNI调到Native code中来。Mono的框架其实也是类似的,CLI 代码要实现平台相关的调用或是调用已有的Native library,最终还是要通过一套类似于JNI的接口。
一般地,从托管到非托管代码的调用有两种方法:
* Internal call(icall):CLI中的很多C#实现最终就会以这种方式调到Mono的runtime中来。通过这种方式,Native端函数的参数只能使用Mono定义的类型。因此适用于CLI调用Mono runtime的情况。对于预定义的Internal call(metadata/icall-def.h),它们的信息记录在一系列静态数组(如icall_type_name, icall_names)中,由于icall-def.h中的类名和方法名都是字典排序的,因此查找时用二分法即可。对于其它的Internal call,可以用mono_add_internal_call()注册。该函数把指定的Internal call放入哈希表(icall_hash,启动时在mono_icall_init()中创建)中。
* P/invoke:在这种调用方式中,函数参数会被Marshal(即managed code转为unmanaged code中的等价对象)。前面的Internal call由于主要用于Mono内部调用,因此参数类型都可以是Mono的内部类型,调用者和被调用者都理解。但如果是外部库,里面都是C/C++的类型,这时就要做一层参数转化了,即前面说的Marshal。关于P/Invoke可以参见http://www.mono-project.com/DllImport
相反地,从非托管代码到托管代码一般是通过mono_runtime_invoke(),官方文档给了个例子:
clazz = mono_object_get_class (obj);
method = mono_class_get_method_from_name (clazz, "Add", 1);
mono_runtime_invoke (method, obj, args, &exception);
流程是不是和JNI很像?只是名字换了下而已。
六、线程池
应用程序或者Mono runtime中的一些异步任务可以交由单独线程完成。Mono中提供了两个线程池:async_tp和async_io_tp。往线程池里加线程的函数为threadpool_append_jobs(),当第一次试图往里边加线程时,会进行初始化,即起一个"Monitor"线程(该线程执行monitor_thread())。这个Monitor线程是做什么用的呢?一会儿会用到。现在假设程序调用了System.Threading.QueueUserWorkItem(),Mono要为其创建线程,于是调用threadpool_append_jobs(),但其实这时还不是真正创建了目标线程,只是加入到线程池队列(async_tp->queue或async_io_tp->queue)中而已。然后前面创建的Monitor线程会检查线程池队列,如果需要,这时候再创建线程。源码中流程如下:
当需要添加新线程执行任务时:
icall_append_job()/threadpool_thread_job()
threadpool_append_jobs()
if (tp->pool_status == 0) // 未初始化
mono_thread_create_internal() // 创建"Monitor"线程
mono_cq_enqueue() // 加入到线程池队列
Monitor线程会从线程池队列中取出线程信息,然后创建线程:
monitor_thread()
for (async_tp and async_io_tp)
if (mono_cq_count(tp->queue) > 0) // 有线程需要创建
threadpool_start_thread(); // 创建线程
一些参数资料
Working With SGen: http://www.mono-project.com/Working_With_SGen
Garbage Collection: http://msdn.microsoft.com/en-us/library/vstudio/0xy59wtx%28v=vs.100%29.aspx
Interop with Native Libraries: http://www.mono-project.com/DllImport
Generational GC: http://www.mono-project.com/Generational_GC#Fixed_Heap
Embedding Mono: http://www.mono-project.com/Embedding_Mono
Mostly Software: http://schani.wordpress.com/tag/mono/
Implementing a Dispose Method: http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx
Implementing Finalize and Dispose to Clean Up Unmanaged Resources: http://msdn.microsoft.com/en-us/library/vstudio/b1yfkh5e%28v=vs.100%29.aspx
OpCodeEmulation: https://monoruntime.wordpress.com/tag/icall/
Debugging: http://www.mono-project.com/Debugging
Dtrace: http://www.mono-project.com/SGen_DTrace
Marshalling In Runtime: https://monoruntime.wordpress.com/tag/runtime-invoke-wrapper/
Performance Tips:http://www.mono-project.com/Performance_Tips