java jdmp 例子_CLR 相比 JVM有哪些先进之处？

虽然只写了一半但还是先发出来免得坑掉。后面边讨论边更新吧…

这个问题原文是：CLR 相比 JVM有哪些先进之处？留下备份。

首先这个问题按其原样无法回答，因为CLR与JVM不是可比较的对象。

CLR(Common Language Runtime)是CLI(Common Language Infrastructure)规范中的VES(Virtual Execution System)的一种具体实现，而“JVM”不指定实现的话只能说是一种抽象的规范。

适合比较的对象是：

规范层面：CLI vs JVM

实现层面：CLR / Mono 等 vs HotSpot VM / J9 VM / JRockit VM 等

从规范层面看的话，CLI规范ECMA-335当前最新的版本是2012年出的第6版。我没太跟进新的CLI规范所以不确定这个版本的CLI与哪个版本的.NET Framework里的CLR对应。

JVM规范The Java® Virtual Machine Specification当前最新的版本则是2015年出的Java SE 8版。

在规范层面上，当前的CLI完胜当前的JVM。

《Virtual Machines: Versatile Platforms for Systems and Processes》一书中有一章专门对比介绍了CLI与JVM的设计，值得一读。

JVM规范由Sun最初的JVM实现(后来称为Classic VM)抽象而来，然后几乎没有大的改动。后来的更新主要添加了Class文件对泛型信息的有限记录、注解(annotation)支持、字节码校验器的更新(split verifier / type checking verifier)、invokedynamic及MethodHandle支持、default method支持等。

最初的JVM规范虽然也提到它“可以支持多种语言”，但主要目的还是支持Java一种语言的执行，直到Java 7添加了JSR 292(invokedynamic与MethodHandle)后才有了专门为Java以外的语言设计的功能。

CLI由.NET最初的CLR实现抽象而来，然后与CLR一起逐渐进化。它出现的时间毕竟比JVM规范晚许多，而且一开始就以支持多种语言、多种范型的执行与互操作为设计目的，自然设计得更完善。对历史有兴趣的同学可以搜搜“Project 7”看。

Interviewer: I've heard that there was a project where Microsoft started to inte...

Don Syme: That's a small part of the sequence. The visional design of the .NET platform was very much expected to be a multi-language platform from the start. Right back in 1998, just in fact as our research group in programming languages started at Microsoft and I joined the team and then other 10 of us joined the team, we were approached by a guy called James Plamondon, who started the project called Project 7, which was about getting 7 academic and 7 industrial programming languages on each side to target the .NET common language runtime and really check out if it was good enough, to see if design changes could be made early on in the design process of .NET to make sure it was good enough for a range of programming languages.Project 7的参与方尝试了将许多种语言移植到CLR上，包括C、Pascal、Cobol (Fujitsu)、Fortran (Salford)、Haskell、Standard ML、Eiffel、Active Oberon for .NET (ETH)、Gardens Point Component Pascal (QUT)等等。

后来还有更进一步的“Project 7+”。

Technical Overview of the Common Language Runtime

要追寻CLR更早的黑历史就不得不提微软的Visual J++。请跳传送门：微软当年的 J++ 究竟是什么？为什么 Sun 要告它？ - RednaxelaFX 的回答

下面先列举一些点提醒我回头更新…

Assembly vs Class文件

常量池以stream的方式存在

可以有strong name

CIL(Common Intermediate Language) / MSIL vs Java字节码

CIL不仅有二进制形式的规范，而且还有标准的文本形式语法；Java字节码只有二进制形式的规范

局部变量区里无论什么类型的值都使用1个slot，而JVM则是long和double用相邻的2个slot

异常处理支持filter

支持具现化泛型(reified generics)

泛型支持声明点协变/逆变(declaration-site variance)Java语言层面的泛型则是支持使用点协变/逆变(use-site variance)

支持无符号整数类型(unsigned)

支持用户自定义值类型(value type)

支持对用户自定义值类型指定显式内存布局，可以模拟C的struct和union以便互操作(StructLayout)

支持检查溢出的算术运算(checked arithmetic)

支持有保证的尾调用(tail call)

支持unsafe verifiable代码

支持轻量代码生成(LCG，Lightweight Code Generation)

支持委托类型(Delegate / MulticastDelegate)CLI Delegate的single cast版本与Java 7的MethodHandle有相似之处

支持方便的P/Invoke和Reverse P/Invoke

不支持自定义类加载器(custom class loader)。JVM上过于灵活的ClassLoader简直是头疼的要命，不支持这个简直好。

CLI里藏的私货：Assembly采用PE(Portable Executable)格式。PE是Windows上原生的可执行文件格式。

CLR与Windows的整合

Windows Loader可以直接识别.NET Assembly并启动CLR来执行程序。

Windows对GAC(Global Assembly Cache)有文件系统层面的特殊处理，“Fusion”。

与COM有良好的互操作能力。毕竟CLR原本就是希望设计成下一代COM，原本还用过COR这个名字(COM Object Runtime)。

分块式GC堆(Chunked GC Heap)，可以自动扩张和收缩GC堆的大小，并且在Windows这种地址空间比较破碎的环境中可以有效的利用地址空间里的空隙。对应的，JRockit在Windows上则是用filler object来利用空隙。

GC堆分为多个空间，特别是高频堆/低频堆(high-frequency heap / low-frequency heap)的划分很有趣。

GC支持固定住对象(Object Pinning)

GC提供API让应用程序可以指定native对象的内存压力，以便GC与native协调工作(System.GC.AddMemoryPressure Method (Int64))

支持Windows的结构化异常处理(SEH)。

CLR 与 一些JVM实现之间有对应物的

CLR：DAC / SOS扩展；HotSpot VM：Serviceability Agent；J9 VM：DTFJ / jdmpview

CLR：CAS(Code Access Security)与 JVM的沙箱