class="topic_img" alt=""/>
英文原文：Mono Adopts .NET Source Code
Mono 4.0 发布说明的草稿目前已经提交，在新版本的诸多变更之中，值得注意的一点是 Mono 团队开始采纳微软 CoreCLR 项目中的源代码了。
让我们说得更准确一些，微软实际上一共推出了三个以 MIT 方式授权的源代码集。
由于 CoreCLR 项目本身依然还不够稳定，因此 Mono 团队目前主要专注于 ReferenceSource 项目中的代码。团队的短期目标是将 Mono 项目中一些有 bug 或未完成的组件替换为 .NET 的对应代码，你可以在 Trello 网站上跟踪该项目的进展情况。
除了 Decimal 类之外，以下命名空间中的代码也都被替换为 ReferenceSource 项目中的源代码了：
而其它命名空间中也有多个类的源代码已经整合到 Mono 项目中了
不再支持的特性
Mono 将不再支持生成对应 .NET 4.0 或更早版本的程序集了，在新的版本中只支持生成 .NET 4.5 以及基于移动档案的程序集。这一变动引起了那些使用 Unity 进行开发的使用者的疑虑，因为 Unity 的开发目前还依赖于某个早期版本的 Mono 中对 .NET 3.5 的实现。
新版本也将不再提供对 Entity Framework 的“内置支持”，因为毕竟大多数用户都会选择使用 NuGet 下载的 EF 版本进行开发。与之类似的是，Mono 中也不再提供自己的 Npgsql 驱动了。
之前，Mono 对于浮点数的操作默认是使用最大精度的。虽然使用 64 位算法进行 32 位浮点数操作同样是安全的，但这种方式对于性能会带来不利的影响。因此，新版本中提供了一个选项，可以选择进行 32 位的计算。
方法的内联也得到了改进。“我们现在能够对最多 8 个机器字长的数据结构的拷贝进行内联，而之前只支持最多 5 个机器字长。超过 8 个字长的数值仍将使用 memcpy 指令以完成操作”。
此外，对于原子操作的运行方式也有某些地方进行了变更。
现在，JIT 能够将框架中的所有原子方法认可为固有方法，并进行内联，这一点利益于平台中某些特定代码的功能。这些方法包括 Interlocked 和 Volatile 的所有方法，以及 Thread 类中的 MemoryBarrier、VolatileRead 和 VolatileWrite 方法。
在 x86 及 64 位机器上，Thread.MemoryBarrier 的实现方式选择了使用 mfence 指令，而不是使用 lock add rsp,0 指令。此外，Interlocked.Exchange 的实现使用了 xchg [dst], val 指令，而不是之前那种更耗性能的 lock cmpxchg [dst], val 循环方式。
对于使用获取/释放语法的原子方法来说，我们将为这些语法生成内存屏障，而不是使用过于严格的顺序一致性方式。
相关文章
