为什么Java有GC调优而没听说过有CLR的GC调优

在很多的场合我都遇到过一些群友提这样的一些问题:

为什么Java有GC调优而CLR没有听说过有GC调优呢? 到底是Java的JVM GC比较强还是C#使用的.NET CLR的GC比较强呢? 其实业内已经有几位大佬的高赞文章和大家分享一下,主要讨论JVM和CLR还有GC调优,今天就借用大佬的回答给大家分享一下。

R大的回答
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
【为什么Java有GC调优而没听说过有CLR的GC调优】首先给大家介绍一下R大,R大网名叫RednaxelaFX,南京大学毕业巨佬,主攻高级编程语言虚拟机的设计与实现,对于C# .NET CLR有非常深入的研究和了解。先后加入阿里、Oracle、Azul System从事JVM虚拟机开发的工作(HotSpot JVM and Zing JVM)。现在在Databricks从事Spark开发工作。
这里R大主要就CLR上几种调优方式和为什么CLR不需要xmx、xmn等参数给出了原因
因为题主您就是没听说过 >_<
假定题主说的是下面三个层面的调优的头两种情况:
对VM的配置参数调优(例如GC参数) 对应用程序自身的代码调优 对VM自身的实现调优

(2)的话无论什么语言什么环境都好,追求性能的人肯定都有在做。Java和.NET都有好用的profiler可以帮助这方面的调查和调优。
有时候参数调优还不够的地方,也只能自己改自己的应用代码来解决问题了。请看一个经典案例:
In managed code we trust, our recent battles with the .NET Garbage Collector
(3)的话,CLR还没开源的时候,也无从调起。倒是有不少人给Mono贡献改进性能的patch,也算是广义上“.NET”的VM实现层面调优吧。
在CoreCLR开源后,也有不少人给CoreCLR贡献各种patch呢,包括“调优”。
.NET码农们以前时不时会中招的一种地方是程序进入GC的耗时(time-to-GC),也就是从CLR说“我要开始做GC了”到“真正开始做GC”之间的耗时。这里主要开销来自请求所有应用线程暂停(SuspendEE),这些线程要多久才完成对该请求的响应。听说过这个过程中会发生“250ms的倍数的等待时间”不?请跳传送门:
Garbage Collection Thread Suspension Delay (250ms Multiples)
像这种问题就是不进到VM内部做修改的话无法解决的。
(1)的话,其实就算当年CLR还没开源的时候,CLR也是有调优参数可以配置的呢。
最经典的就是选择试用Workstation GC(WKS GC)或者Server GC(SVR GC)。见过参数不?
后来可以配置使用Concurrent GC、Background Workstation GC、Background Server GC等。
用户还可以在代码里通过 GCSettings.LatencyMode 属性来影响GC的行为。
看,调优参数列表之一:
Runtime Settings Schema
不过CLR跟HotSpot VM在配置上有一个显著的区别,就是CLR不需要用户指定一个“GC堆的最大大小”。这跟CLR的GC堆的基础设计思路有关系。
HotSpot VM的GC堆一定要使用连续的虚拟地址空间。VM在启动的时候会一口气reserve GC所需要的整个地址空间,然后再按需commit。-Xmx会参与到GC堆最大大小的计算中。
CLR的GC堆则是分段式的(segemented),GC堆所用的空间会一个个segment分配,用满了一个再去分配一个新的;segment不需要在连续的地址空间上。这样GC堆可以按需自动增长或者缩减,可以一直增长到耗尽虚拟地址空间或者达到配额。
CLR这种分段式GC堆的好处是,在Windows上,特别是32位Windows上,虚拟地址空间中用户程序可以用的部分是比较零碎的,想要用到尽就不能对“连续的地址空间”有太多要求,这种条件下CLR跑在Windows上就可以充分利用资源。
而且这样一来,用户就不用头疼实现想好要配置多大的堆给CLR用了。反正它需要用多少会自己去增长。这用户体验就比绞尽脑汁想个好-Xmx要爽。
这种做法的坏处…怎能没有坏处呢。坏处也有若干。其中一个就是在这样的堆上实现的分代式GC的write barrier效率会比HotSpot那种用连续地址空间的要差一些。而且segmented heap实现起来也稍微复杂一些。
CLR 相比 JVM有哪些先进之处?
CLR 相比 JVM有哪些先进之处? - RednaxelaFX的回答 - 知乎 https://www.zhihu.com/questio...
这里R大主要介绍了下CLR和JVM的不同,和下面hez大佬的回答可以对应起来
虽然只写了一半但还是先发出来免得坑掉。后面边讨论边更新吧…
这个问题原文是:
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) OpenJDK: Valhalla 泛型支持声明点协变/逆变(declaration-site variance) Java语言层面的泛型则是支持使用点协变/逆变(use-site variance) 支持无符号整数类型(unsigned) 支持用户自定义值类型(value type) OpenJDK: Valhalla 支持对用户自定义值类型指定显式内存布局,可以模拟C的struct和union以便互操作(StructLayout) OpenJDK: Panama 支持检查溢出的算术运算(checked arithmetic) 支持有保证的尾调用(tail call) 支持unsafe verifiable代码 支持轻量代码生成(LCG,Lightweight Code Generation) 支持委托类型(Delegate / MulticastDelegate) CLI Delegate的single cast版本与Java 7的MethodHandle有相似之处 支持方便的P/Invoke和Reverse P/Invoke OpenJDK: Panama 不支持自定义类加载器(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的沙箱

    推荐阅读