- 浏览: 3014842 次
- 性别:
- 来自: 海外
文章分类
- 全部博客 (430)
- Programming Languages (23)
- Compiler (20)
- Virtual Machine (57)
- Garbage Collection (4)
- HotSpot VM (26)
- Mono (2)
- SSCLI Rotor (1)
- Harmony (0)
- DLR (19)
- Ruby (28)
- C# (38)
- F# (3)
- Haskell (0)
- Scheme (1)
- Regular Expression (5)
- Python (4)
- ECMAScript (2)
- JavaScript (18)
- ActionScript (7)
- Squirrel (2)
- C (6)
- C++ (10)
- D (2)
- .NET (13)
- Java (86)
- Scala (1)
- Groovy (3)
- Optimization (6)
- Data Structure and Algorithm (3)
- Books (4)
- WPF (1)
- Game Engines (7)
- 吉里吉里 (12)
- UML (1)
- Reverse Engineering (11)
- NSIS (4)
- Utilities (3)
- Design Patterns (1)
- Visual Studio (9)
- Windows 7 (3)
- x86 Assembler (1)
- Android (2)
- School Assignment / Test (6)
- Anti-virus (1)
- REST (1)
- Profiling (1)
- misc (39)
- NetOA (12)
- rant (6)
- anime (5)
- Links (12)
- CLR (7)
- GC (1)
- OpenJDK (2)
- JVM (4)
- KVM (0)
- Rhino (1)
- LINQ (2)
- JScript (0)
- Nashorn (0)
- Dalvik (1)
- DTrace (0)
- LLVM (0)
- MSIL (0)
最新评论
-
mldxs:
虽然很多还是看不懂,写的很好!
虚拟机随谈(一):解释器,树遍历解释器,基于栈与基于寄存器,大杂烩 -
HanyuKing:
Java的多维数组 -
funnyone:
Java 8的default method与method resolution -
ljs_nogard:
Xamarin workbook - .Net Core 中不 ...
LINQ的恶搞…… -
txm119161336:
allocatestlye1 顺序为 // Fields o ...
最近做的两次Java/JVM分享的概要
使用Oracle/Sun JDK来运行Java程序的时候,大家或许有用过jstat工具来观察GC的统计数据,例如上一篇日志里的
以前写过一帖说明jstat工具显示的读数与jvmstat计数器之前的关系:用Java获取full GC的次数?(2)
可以知道,FGC列表示的是full GC次数,对应的jvmstat计数器是sun.gc.collector.1.invocations:
但是这个计数器在CMS GC里到底是指什么的次数呢?
在JDK 6的HotSpot VM中,Oracle/Sun有官方支持的GC只有CMS比较特殊(Garbage-First在JDK6里还没正式支持,不算在内):其它几种GC的每个周期都是完全stop-the-world的;而CMS的每个并发GC周期则有两个stop-the-world阶段——initial mark与final re-mark,其它阶段是与应用程序一起并发执行的。
如果CMS并发GC过程中出现了concurrent mode failure的话那么接下来就会做一次mark-sweep-compact的full GC,这个是完全stop-the-world的。
正是这个特征,使得CMS的每个并发GC周期总共会更新full GC计数器两次,initial mark与final re-mark各一次;如果出现concurrent mode failure,则接下来的full GC自己算一次。
如果说大家关心“GC次数”主要关心的其实是应用暂停次数的话,这么做倒也合理。但要注意的是在CMS里“暂停次数”并不等同于“GC次数”,CMS并发GC的一个周期叫“一次GC”但暂停了两次。
只不过有些人在从其它GC改为用CMS的时候会对“full GC次数”的显著增加感到不满,觉得是不是应该想办法调优来让“full GC次数”降下来。这里有几点:
1、CMS GC的设计初衷就是以降低GC latency为目标。如果一个应用产生垃圾的速度非常高的话,原本清除那些垃圾需要的时间并不会消失,CMS只是把它从一个大暂停分散到了多个阶段上,其中部分是暂停的,部分是并发的。所以暂停的次数本来就应该会增加,而每次停顿的时间则应该比较短——这是设计取舍的倾向性导致的。
2、为了更有效的实现并发,CMS GC进行的过程中必须保证堆里还有足够剩余空间来留给应用去分配对象,所以比起ParallelScavenge等别的实现CMS必须要提早一些触发并发GC的启动。如果从ParallelScavange迁移到CMS的时候不同事增大GC堆的大小,那么可以看到同样的应用在GC堆的占用率更低的时候就会触发GC了,所以GC次数增加了。
3、CMS GC中,“full GC次数”的计数器在每个并发GC周期里是增加2而不是增加1的。这也就是这篇日志最想说明的点:这个计数器说明了GC造成的应用暂停的次数,但并不代表CMS的并发GC周期的个数。由于full GC的计数器也会在完全stop-the-world的full GC中增加1,所以这个计数器也不准确代表并发GC周期个数的正好两倍。
4、一个CMS并发GC周期的触发原因只有一个;其中的两次暂停都是同一个原因引致的,例如说最初CMS old gen或者perm gen的使用率已经超过了某个阈值之类。
======================================================================
实现细节感兴趣的同学们,看代码~
CMSCollector里有_gc_counters用于记录jvmstat(或者说PerfData)需要的统计数据。这是个CollectorCounters类型的对象,里面有_invocations成员是用来记录GC次数的。
TraceCollectorStats用于辅助记录GC的次数。它在构造器里会将传入的CollectorCounters的invocation_counter()计数器自增1(自增1的具体逻辑在其基类的PerfTraceTimedEvent的构造器里)。
计数器增加1就是这里的_eventp->inc();
HotSpot里每个stop-the-world行为都用一个VM_Operation包装起来。与CMS相关的两个VM_Operation就是VM_CMS_Initial_Mark与VM_CMS_Final_Mark。
这两个VM_Operation的核心部分都调用了下面这个函数:
留意到其中的TraceCollectorStats tcs(counters());了么?这就让full GC的计数器增加了1。
也就是说CMS GC的两个暂停阶段各自会让full GC计数器增加1,于是整个CMS并发GC周期里该计数器就会增加2了。
======================================================================
追加:有人提醒我有这么一篇文章:
JDK6 Update 23 changes CMS Collection counters
所以顺便一提,我这篇blog用的是JDK 6 update 25对应的HotSpot 20来讲的。
如果大家关注JMX读出来CMS collections次数,请留意一下上面链接的文章。
$ jstat -gcutil `pgrep -u admin java` S0 S1 E O P YGC YGCT FGC FGCT GCT 37.21 0.00 99.81 12.87 76.82 1767 196.843 3085 2998.088 3194.931
以前写过一帖说明jstat工具显示的读数与jvmstat计数器之前的关系:用Java获取full GC的次数?(2)
可以知道,FGC列表示的是full GC次数,对应的jvmstat计数器是sun.gc.collector.1.invocations:
column { header "^FGC^" /* Full Collections */ data sun.gc.collector.1.invocations align right width 5 scale raw format "0" }
但是这个计数器在CMS GC里到底是指什么的次数呢?
在JDK 6的HotSpot VM中,Oracle/Sun有官方支持的GC只有CMS比较特殊(Garbage-First在JDK6里还没正式支持,不算在内):其它几种GC的每个周期都是完全stop-the-world的;而CMS的每个并发GC周期则有两个stop-the-world阶段——initial mark与final re-mark,其它阶段是与应用程序一起并发执行的。
Memory Management in the Java HotSpot™ Virtual Machine 写道
如果CMS并发GC过程中出现了concurrent mode failure的话那么接下来就会做一次mark-sweep-compact的full GC,这个是完全stop-the-world的。
正是这个特征,使得CMS的每个并发GC周期总共会更新full GC计数器两次,initial mark与final re-mark各一次;如果出现concurrent mode failure,则接下来的full GC自己算一次。
如果说大家关心“GC次数”主要关心的其实是应用暂停次数的话,这么做倒也合理。但要注意的是在CMS里“暂停次数”并不等同于“GC次数”,CMS并发GC的一个周期叫“一次GC”但暂停了两次。
只不过有些人在从其它GC改为用CMS的时候会对“full GC次数”的显著增加感到不满,觉得是不是应该想办法调优来让“full GC次数”降下来。这里有几点:
1、CMS GC的设计初衷就是以降低GC latency为目标。如果一个应用产生垃圾的速度非常高的话,原本清除那些垃圾需要的时间并不会消失,CMS只是把它从一个大暂停分散到了多个阶段上,其中部分是暂停的,部分是并发的。所以暂停的次数本来就应该会增加,而每次停顿的时间则应该比较短——这是设计取舍的倾向性导致的。
2、为了更有效的实现并发,CMS GC进行的过程中必须保证堆里还有足够剩余空间来留给应用去分配对象,所以比起ParallelScavenge等别的实现CMS必须要提早一些触发并发GC的启动。如果从ParallelScavange迁移到CMS的时候不同事增大GC堆的大小,那么可以看到同样的应用在GC堆的占用率更低的时候就会触发GC了,所以GC次数增加了。
3、CMS GC中,“full GC次数”的计数器在每个并发GC周期里是增加2而不是增加1的。这也就是这篇日志最想说明的点:这个计数器说明了GC造成的应用暂停的次数,但并不代表CMS的并发GC周期的个数。由于full GC的计数器也会在完全stop-the-world的full GC中增加1,所以这个计数器也不准确代表并发GC周期个数的正好两倍。
4、一个CMS并发GC周期的触发原因只有一个;其中的两次暂停都是同一个原因引致的,例如说最初CMS old gen或者perm gen的使用率已经超过了某个阈值之类。
======================================================================
实现细节感兴趣的同学们,看代码~
CMSCollector里有_gc_counters用于记录jvmstat(或者说PerfData)需要的统计数据。这是个CollectorCounters类型的对象,里面有_invocations成员是用来记录GC次数的。
CollectorCounters::CollectorCounters(const char* name, int ordinal) { if (UsePerfData) { EXCEPTION_MARK; ResourceMark rm; const char* cns = PerfDataManager::name_space("collector", ordinal); _name_space = NEW_C_HEAP_ARRAY(char, strlen(cns)+1); strcpy(_name_space, cns); // ... cname = PerfDataManager::counter_name(_name_space, "invocations"); _invocations = PerfDataManager::create_counter(SUN_GC, cname, PerfData::U_Events, CHECK); // ... } }
TraceCollectorStats用于辅助记录GC的次数。它在构造器里会将传入的CollectorCounters的invocation_counter()计数器自增1(自增1的具体逻辑在其基类的PerfTraceTimedEvent的构造器里)。
class TraceCollectorStats: public PerfTraceTimedEvent { protected: CollectorCounters* _c; public: inline TraceCollectorStats(CollectorCounters* c) : PerfTraceTimedEvent(c->time_counter(), c->invocation_counter()), _c(c) { if (UsePerfData) { _c->last_entry_counter()->set_value(os::elapsed_counter()); } } inline ~TraceCollectorStats() { if (UsePerfData) _c->last_exit_counter()->set_value(os::elapsed_counter()); } };
class PerfTraceTimedEvent : public PerfTraceTime { protected: PerfLongCounter* _eventp; public: inline PerfTraceTimedEvent(PerfLongCounter* timerp, PerfLongCounter* eventp): PerfTraceTime(timerp), _eventp(eventp) { if (!UsePerfData) return; _eventp->inc(); } inline PerfTraceTimedEvent(PerfLongCounter* timerp, PerfLongCounter* eventp, int* recursion_counter): PerfTraceTime(timerp, recursion_counter), _eventp(eventp) { if (!UsePerfData) return; _eventp->inc(); } };
计数器增加1就是这里的_eventp->inc();
HotSpot里每个stop-the-world行为都用一个VM_Operation包装起来。与CMS相关的两个VM_Operation就是VM_CMS_Initial_Mark与VM_CMS_Final_Mark。
// The VM_CMS_Operation is slightly different from // a VM_GC_Operation -- and would not have subclassed easily // to VM_GC_Operation without several changes to VM_GC_Operation. // To minimize the changes, we have replicated some of the VM_GC_Operation // functionality here. We will consolidate that back by doing subclassing // as appropriate in Dolphin. // // VM_Operation // VM_CMS_Operation // - implements the common portion of work done in support // of CMS' stop-world phases (initial mark and remark). // // VM_CMS_Initial_Mark // VM_CMS_Final_Mark //
这两个VM_Operation的核心部分都调用了下面这个函数:
void CMSCollector::do_CMS_operation(CMS_op_type op) { gclog_or_tty->date_stamp(PrintGC && PrintGCDateStamps); TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty); TraceTime t("GC", PrintGC, !PrintGCDetails, gclog_or_tty); TraceCollectorStats tcs(counters()); switch (op) { case CMS_op_checkpointRootsInitial: { SvcGCMarker sgcm(SvcGCMarker::OTHER); checkpointRootsInitial(true); // asynch if (PrintGC) { _cmsGen->printOccupancy("initial-mark"); } break; } case CMS_op_checkpointRootsFinal: { SvcGCMarker sgcm(SvcGCMarker::OTHER); checkpointRootsFinal(true, // asynch false, // !clear_all_soft_refs false); // !init_mark_was_synchronous if (PrintGC) { _cmsGen->printOccupancy("remark"); } break; } default: fatal("No such CMS_op"); } }
留意到其中的TraceCollectorStats tcs(counters());了么?这就让full GC的计数器增加了1。
也就是说CMS GC的两个暂停阶段各自会让full GC计数器增加1,于是整个CMS并发GC周期里该计数器就会增加2了。
======================================================================
追加:有人提醒我有这么一篇文章:
JDK6 Update 23 changes CMS Collection counters
所以顺便一提,我这篇blog用的是JDK 6 update 25对应的HotSpot 20来讲的。
如果大家关注JMX读出来CMS collections次数,请留意一下上面链接的文章。
发表评论
-
The Prehistory of Java, HotSpot and Train
2014-06-02 08:18 0http://cs.gmu.edu/cne/itcore/vi ... -
MSJVM and Sun 1.0.x/1.1.x
2014-05-20 18:50 0当年的survey paper: http://www.sym ... -
Sun JDK1.4.2_28有TieredCompilation
2014-05-12 08:48 0原来以前Sun的JDK 1.4.2 update 28就已经有 ... -
IBM JVM notes (2014 ver)
2014-05-11 07:16 0Sovereign JIT http://publib.bou ... -
class data sharing by Apple
2014-03-28 05:17 0class data sharing is implement ... -
Java 8与静态工具类
2014-03-19 08:43 16131以前要在Java里实现所谓“静态工具类”(static uti ... -
Java 8的default method与method resolution
2014-03-19 02:23 10324先看看下面这个代码例子, interface IFoo { ... -
HotSpot Server VM与Server Class Machine
2014-02-18 13:21 0HotSpot VM历来有Client VM与Server V ... -
Java 8的lambda表达式在OpenJDK8中的实现
2014-02-04 12:08 0三月份JDK8就要发布首发了,现在JDK8 release c ... -
GC stack map与deopt stack map的异同
2014-01-08 09:56 0两者之间不并存在包含关系。它们有交集,但也各自有特别的地方。 ... -
HotSpot Server Compiler与data-flow analysis
2014-01-07 17:41 0http://en.wikipedia.org/wiki/Da ... -
基于LLVM实现VM的JIT的一些痛点
2014-01-07 17:25 0同事Philip Reames Sanjoy Das http ... -
tailcall notes
2013-12-27 07:42 0http://blogs.msdn.com/b/clrcode ... -
《自制编程语言》的一些笔记
2013-11-24 00:20 0http://kmaebashi.com/programmer ... -
字符串的一般封装方式的内存布局 (1): 元数据与字符串内容,整体还是分离?
2013-11-07 17:44 22245(Disclaimer:未经许可请 ... -
字符串的一般封装方式的内存布局 (0): 拿在手上的是什么
2013-11-04 18:22 21363(Disclaimer:未经许可请 ... -
字符串的一般封装方式的内存布局
2013-11-01 12:55 0(Disclaimer:未经许可请 ... -
关于string,内存布局,C++ std::string,CoW
2013-10-30 20:45 0(Disclaimer:未经许可请 ... -
对C语义的for循环的基本代码生成模式
2013-10-19 23:12 21734之前有同学在做龙书(第二版)题目,做到8.4的练习,跟我对答案 ... -
Java的instanceof是如何实现的
2013-09-22 16:57 0Java语言规范,Java SE 7版 http://docs ...
相关推荐
java查看哪个进程频繁GC垃圾回收
jstat命令手册.pdf
本文是Javascript统计学库jStat的中文参考手册。jStat是用Javascript编写的统计学库,它可以让你进行高级的统计操作而不需要专门的统计语言(如MATLAB或R)。
jstat - Java Virtual Machine Statistics Monitoring Tool jstat官方介绍
jmap jstat等命令介绍,如何监控tomcat内存使用情况的资料
jstat js正态分布函数库 var NormalDistribution = require('./jstat').NormalDistribution;
jstat [-命令选项] [vmid] [间隔时间(毫秒)] [查询次数] 注意:使用的jdk版本是jdk8. 二、垃圾回收统计 最常用,可以评估程序内存使用及GC压力整体情况。 指令:jstat -gc pid 指令:jstat -gc pid [interval] ...
jstat-1压缩包1111
jmap、jstack、jstat组合使用定位jvm问题
jstat用户监控基于HotSpot的JVM,对其堆的使用情况进行实时的命令行统计
java应用运行过程中难免会出现问题,特别是在生产环境,发生异常或宕机情况,需要诊断与分析,定位原因,进行优化,避免下次再次出现问题。 虽然现在有很多可视化工具,使用起来比命令行更方便,但我们仍需要对基本...
与大多数库相比,jStat提供的功能更多,包括weibull,cauchy,泊松,超几何和beta分布。 对于大多数分布,jStat提供pdf,cdf,反函数,均值,众数,方差和样本函数,从而允许进行更复杂的计算。 注意:以前区分大...
jstat.xlsx
前端项目-jstat,Statistical Library for JavaScript
jstat-示例 使用示例 实例图 机器学习 :线性回归 :非线性回归 :使用香草KNN算法进行分类 :具有多个线程的KNN分类 :使用KMeans进行聚类 :后勤分类 :使用正则化LassoRegularizer和RidgeRegularizer线性...
使用jstat命令观察GC的过程 jstat -gc 94223 2000 1000 通过GCViewer工具查看GC日志 为了找到内存泄漏点,我们通过jmap工具生成Heap Dump jmap -dump:live,format = b,file = 94223.bin 94223 用Eclipse Memory ...
jStat是一个处理频道统计信息的IRC机器人(例如,排名前10的海报等)
在调用时, JTune 在给定 pid 中捕捉 jstat 的输出,以及样本时间内的 GC 日志数据。 FAQ Q: 我必须以 root 的身份运行 jtune.py 吗? A: 你应该以你要分析的 Java 进程的用户(或者 root)来运行。 Q: 它...
JVM监控工具介绍jstack, jconsole, jinfo, jmap, jdb, jstat.doc
角jstat jStat统计库的角度包装