DefNew ParNew

转自:http://hllvm.group.iteye.com/group/topic/37095


串行收集器:
DefNew:是使用-XX:+UseSerialGC(新生代,老年代都使用串行回收收集器)。
并行收集器:
ParNew:是使用-XX:+UseParNewGC(新生代使用并行收集器,老年代使用串行回收收集器)或者-XX:+UseConcMarkSweepGC(新生代使用并行收集器,老年代使用CMS)。
PSYoungGen:是使用-XX:+UseParallelOldGC(新生代,老年代都使用并行回收收集器)或者-XX:+UseParallelGC(新生代使用并行回收收集器,老年代使用串行收集器)
garbage-first heap:是使用-XX:+UseG1GC(G1收集器)


====================================================================================

呃。HotSpot VM的GC组老人之一Jon Masamitsu很久之前就写过blog讲解这个:https://blogs.oracle.com/jonthecollector/entry/our_collectors 

简单来说,有这么多东西反映了HotSpot VM的开发历史和实现细节。我在写篇东西讲述这部分历史,哪天写完的话在这边也放个链接嗯。 

DefNewGeneration是default new generation 
ParNewGeneration是parallel new generation 

原本HotSpot VM里没有并行GC,当时就只有NewGeneration;后来准备要加入young gen的并行GC,就把原本的NewGeneration改名为DefNewGeneration,然后把新加的并行版叫做ParNewGeneration。 

这些XXXGeneration都在HotSpot VM的“分代式GC框架”内。本来HotSpot VM鼓励开发者尽量在这个框架内开发GC,但后来有个开发就是不愿意被这框架憋着,自己硬写了个没用写框架的新并行GC,并拉拢性能测试团队用这个并行GC来跑分,成绩也还不错,于是这个GC就放进HotSpot VM里了。这就是我们现在看到的ParallelScavenge。 

(结果就是HotSpot GC组不得不维护两个功能几乎一样的并行GC。其实是件很头疼的事情嗯) 

Scavenge或者叫scavenging GC,其实就是copying GC的另一种叫法而已。HotSpot VM里的GC都是在minor GC收集器里用scavenging的,DefNew、ParNew和ParallelScavenge都是,只不过DefNew是串行的copying GC,而后两者是并行的copying GC。 

由此名字就可以知道,“ParallelScavenge”的初衷就是把“scavenge”给并行化。换句话说就是把minor GC并行化。至于full GC,那不是当初关注的重点。 

把GC并行化的目的是想提高GC速度,也就是提高吞吐量(throughput)。所以其实ParNew与ParallelScavenge都可叫做Throughput GC。 
但是在HotSpot VM的术语里“Throughput GC”通常特指“ParallelScavenge”。 

================================ 

ParallelScavenge和ParNew都是并行GC,主要是并行收集young gen,目的和性能其实都差不多。最明显的区别有下面几点: 
1、PS以前是广度优先顺序来遍历对象图的,JDK6的时候改为默认用深度优先顺序遍历,并留有一个UseDepthFirstScavengeOrder参数来选择是用深度还是广度优先。在JDK6u18之后这个参数被去掉,PS变为只用深度优先遍历。ParNew则是一直都只用广度优先顺序来遍历 
2、PS完整实现了adaptive size policy,而ParNew及“分代式GC框架”内的其它GC都没有实现(倒不是不能实现,就是麻烦+没人力资源去做)。所以千万千万别在用ParNew+CMS的组合下用UseAdaptiveSizePolicy,请只在使用UseParallelGC或UseParallelOldGC的时候用它。 
3、由于在“分代式GC框架”内,ParNew可以跟CMS搭配使用,而ParallelScavenge不能。当时ParNew GC被从Exact VM移植到HotSpot VM的最大原因就是为了跟CMS搭配使用。 
4、在PS成为主要的throughput GC之后,它还实现了针对NUMA的优化;而ParNew一直没有得到NUMA优化的实现。 

================================ 

还有一点要注意:上面说ParallelScavenge并行收集young gen,那old/perm gen呢? 

其实最初的ParallelScavenge的目标只是并行收集young gen,而full GC的实际实现还是跟serial GC一样。只不过因为它没有用HotSpot VM的generational GC framework,自己实现了一个CollectedHeap的子类ParallelScavengeHeap,里面都弄了独立的一套接口,而跟HotSpot当时其它几个GC不兼容。其实真的有用的代码大部分就在PSScavenge(=“ParallelScavenge的Scavenge”)里,也就是负责minor GC的收集器;而负责full GC的收集器叫做PSMarkSweep(=“ParallelScavenge的MarkSweep”),其实只是在serial GC的核心外面套了层皮而已,骨子里是一样的LISP2算法的mark-compact收集器(别被名字骗了,它并不是一个mark-sweep收集器)。 

当启用-XX:+UseParallelGC时,用的就是PSScavenge+PSMarkSweep的组合。 
这是名副其实的“ParallelScavenge”——只并行化了“scavenge”。 

所以其实非要说对应关系的话,PSScavenge才是真的跟ParNew对等的东西;ParallelScavenge这个名字既指代整套新GC,也可指代其真正卖点的PSScavenge。 

不知道后来什么原因导致full GC的并行化并没有在原本的generational GC framework上进行,而只在ParallelScavenge系上进行了。其成果就是使用了LISP2算法的并行版的full GC收集器,名为PSCompact(=“ParallelScavenge-MarkCompact”),收集整个GC堆。 

当启用-XX:+UseParallelOldGC时,用的就是PSScavenge+PSCompact的组合。 
此时ParallelScavenge其实已经名不符实了——它不只并行化了“scavenge”(minor GC),也并行化了“mark-compact”(full GC)。

展开阅读全文

GC 时 ParNew 大小不变

07-17

在做压力测试,觉得 GC 的 LOG 比较奇怪,GC 前后 ParNew 的大小一直没变,LOG 在下面。rn我不太懂 GC LOG 的格式,哪位老大能否帮忙分析一下。rnParNew 被占满了,又减不下来,程序不是应该报 out of memory 吗?可这个程序,这样跑了一个小时,居然没出错。rnrnrn操作系统:Solaris rnJDK版本:1.4.2 rn服务器:Tomcat5.0.30 rn参数:rnCATALINA_OPTS=" -DJavaApp=CSC -Xmx2048M -Xms2048M -Xmn1024M -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:PermSize=64m -XX:MaxPermSize=128m -XX:MaxNewSize=256m -XX:+PrintGCDetails -Xloggc:/opt/wacos/server/csc/log/gc.log -server -Djava.awt.headless=true "rnrnGC LOG:rn0.000: [GC 0.001: [ParNew: 1046656K->0K(1047616K), 1.7257062 secs] 1046656K->80917K(2096192K), 1.7263158 secs]rn66.994: [GC 66.995: [ParNew: 1046656K->1046656K(1047616K), 0.0000649 secs]66.995: [CMS: 80917K->83334K(1048576K), 2.8593676 secs] 1127573K->83334K(2096192K), 2.8600764 secs]rn131.386: [GC 131.387: [ParNew: 1046656K->1046656K(1047616K), 0.0000634 secs]131.387: [CMS: 83334K->85018K(1048576K), 3.0854086 secs] 1129990K->85018K(2096192K), 3.0862345 secs]rn205.899: [GC 205.899: [ParNew: 1046656K->1046656K(1047616K), 0.0000624 secs]205.899: [CMS: 85018K->87700K(1048576K), 2.8770929 secs] 1131674K->87700K(2096192K), 2.8777912 secs]rn274.861: [GC 274.861: [ParNew: 1046656K->1046656K(1047616K), 0.0000623 secs]274.861: [CMS: 87700K->91613K(1048576K), 3.1890179 secs] 1134356K->91613K(2096192K), 3.1897300 secs]rn366.837: [GC 366.837: [ParNew: 1046656K->1046656K(1047616K), 0.0000617 secs]366.838: [CMS: 91613K->111431K(1048576K), 3.8935320 secs] 1138269K->111431K(2096192K), 3.8942527 secs]rn435.823: [GC 435.823: [ParNew: 1046656K->1046656K(1047616K), 0.0000626 secs]435.823: [CMS: 111431K->106082K(1048576K), 3.2238941 secs] 1158087K->106082K(2096192K), 3.2246735 secs]rn509.418: [GC 509.418: [ParNew: 1046656K->1046656K(1047616K), 0.0000641 secs]509.419: [CMS: 106082K->108634K(1048576K), 3.3599787 secs] 1152738K->108634K(2096192K), 3.3608074 secs]rn577.181: [GC 577.182: [ParNew: 1046656K->1046656K(1047616K), 0.0000625 secs]577.182: [CMS: 108634K->113682K(1048576K), 3.6951130 secs] 1155290K->113682K(2096192K), 3.6957893 secs]rn637.698: [GC 637.699: [ParNew: 1046656K->1046656K(1047616K), 0.0000633 secs]637.699: [CMS: 113682K->115755K(1048576K), 3.6022338 secs] 1160338K->115755K(2096192K), 3.6030499 secs]rn.................................rn.................................rn.................................rn3786.532: [GC 3786.532: [ParNew: 1046656K->1046656K(1047616K), 0.0000614 secs]3786.532: [CMS: 239352K->243197K(1048576K), 6.2094660 secs] 1286008K->243197K(2096192K), 6.2101648 secs]rnrnrn 论坛

没有更多推荐了,返回首页