chenghanpeng/jdk8u60

《JVM G1源码分析和调优》一书参考的代码

jdk8u60's Issues

2.6.1 章节frame结构

_unextented_sp 是用来做栈回溯的，不是异常栈顶指针。

堆内存为什么有慢速分配

我的理解是：因为tlab在E区有固定的占比，默认1%，那么当无法分配新的tlab时，会进入慢速分配，也就是直接在堆上分配。
那为什么不能调高tlab在E区的占比呢？尽可能的使用快速分配，避免慢速分配呢？这样设计可以么

CardTable 与 RSet 的区别

看了书之后我感觉我还是比较难理解 卡表与记忆集之前的区别，按照我现在的理解，貌似他们都是为了方便不同记录不同分区之间的一些引用关系而存在的；

感觉他们都是在干着相同的事情，只是卡表记录着全部分块应用，Rset 只记录部分跨分区之间(老->新;老->老)的引用？

@chenghanpeng

关于TLAB对象分配流程图的问题

作者您好，我在学习第3章 G1的对象分配 的 3.1小节时，有一点疑惑，在本书第45页的对象分配流程图中，关于TLAB剩余对象这部分，我的理解是TLAB剩余空间多的时候，继续分配新的TLAB，当剩余空间不足时，进行大对象的判断。不知道是不是笔误，如果您有时间的话，希望您能指导一下。十分感谢。

对第49页，小标题：1.如何判断TLAB满了有点疑惑。

1，书中写到，当请求对象大于refill_waste时会选择在堆中分配，请问这个堆具体是指的什么，是TLAB吗？
2，当一个1MB的TLAB使用16K，还剩1008K时，为什么内存是直接分配一个新的TLAB，那这1008K的空间岂不是浪费了。个人觉得是否应该是如果新的对象小于refill_waste则继续使用TLAB，否则分配一个新的？

4.2.1 请教Refinement采样线程采样不足的问题

在第四章，4.2.1 书中介绍抽样线程时提到 G1ConcRefinementServiceIntervalMillis 可以控制采样的间隔时间

如果生产中发现采样不足可以减少该时间

这里想请教

1. 如何判断Refinement抽样不足？
2. 抽样不足对GC的影响怎么来进行评估？

缘由也是工作中遇到GC Predicted Pause Time会无故变高，Young Generation同时无故变少很多导致GC频繁，苦于没有好的方案
源码中发现Predicted Pause Time与rs_length相关，可以是没有相应日志可以判断变化的原因。

感谢作者的大作，受益许多

5.3.5 Redirty章节内存复制后的处理

你好大佬, 非常开心能找到这本书解决了我的很多疑惑, 但是在阅读的过程中我还是有一些不太理解的地方, 可以帮忙解答一下吗? 非常感谢!

书中描述的步骤如下:

1. 原引用: Obj5_OHR1.Field1 = Obj2_YHR2
2. Obj2_YHR2 内存复制到 Obj2_YHR3
3. Obj5_OHR1.Field1 = Obj2_YHR3

我本身的知识认知:

1. 每个Java对象对应一个C++对象, 该C++对象内存储MarkWord、Klass引用地址、对象实例数据
2. C++需要申请内存是返回一个句柄(通过Unsafe#allocateMemory方法推断出来的)

疑问点:
GC的时候Obj2由YHR2移动到YHR3, 那么Obj5_OHR1.Field1的引用地址会被修改吗?

1. 如果被修改, 那么JVM是如何通过Java对象地址找到实际内存的位置
2. 如果没有修改, JVM是否维护着一个Map, key是java对象地址, value是C++对象的句柄

《JVM G1源码分析与调优》 书中的异常

《JVM G1源码分析与调优》 P86页，G1ConcRefinementThresholdStep 计算公式错误 ， 根据源码，应该是 _thread_threshold_step = (yellow_zone() - green_zone()) / (worker_thread_num() + 1); (少了个括号)

另 P143页下方“6.并发标记的正确性分析” 里面有一句话： “实际上存在Java根直接引用老生代对象，而不存在新生代对象到老生代的引用” 这句话是错误的吧，还是我理解有问题

望解答

4.6 G1ConcRSLogCacheSize参数介绍card数量的计算

原文是：参数G1ConcRSLogCacheSize，默认值为10，即存储hot card最多为210，也就是1024个。
其中210、1024是如何算出的？

4.6 关于 G1RSetUpdatingPauseTimePercent 描述为GC完成时间的百分比（默认为10%）

第4章， 4.6 介绍G1RSetUpdatingPauseTimePercent的原理时，提到"RSet所用的全部时间不超过GC完成时间的10%“
Oracle的文档有如下描述，大意是指G1RSetUpdatingPauseTimePercent 的分母为MaxGCPauseMillis而不是GC具体完成的时间

G1 tries to schedule concurrent processing of the remembered set updates so that the Update RS phase takes approximately -XX:G1RSetUpdatingPauseTimePercent percent of the allowed maximum pause time. By decreasing this value, G1 usually performs more remembered set update work concurrently.

源码里面用了max_gc_time() 去乘这个G1RSetUpdatingPauseTimePercent，看起来符合上面文档的描述

jdk8u60/hotspot/src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp

Line 1187 in 7e3369b

double update_rs_time_goal_ms = _mmu_tracker->max_gc_time() * MILLIUNITS * G1RSetUpdatingPauseTimePercent / 100.0;

所以想跟作者确认下这个细节的描述是否有不准确的地方 @chenghanpeng