OpenJDK16ZGC源码分析

见贤思齐

动手点关注干货不迷路概览ZGC 在 JDK11 中作为实验性功能引入后，已经经过了 5 个版本的演进，目前较之前版本有了较大的变化。本文将分析 ZGC 的设计思想和原理。ZGC 主要设计理念如下：ZGC 为了支持 TB 级内存，采用了基于 Page 的分页管理（类似于 G1 的 Region）。同时，为了加快内存访问速度，快速的进行并发标记和 relocate，ZGC 新引入了 Color Pointers；Color Pointers 与 Shenandoah GC 使用的 Brooks Pointers 机制不同，依赖内核提供的多视图映射，因此仅能支持部分操作系统的 64 位版本，适用性不如 Shenandoah GC，同时也无法支持指针压缩 CompressedOops。另外，为了高效内存管理，设计了两级内存管理系统。内存管理指针结构zGlobals_x86.cpp//AddressSpace&ointerLayout3//--------------------------------////+--------------------------------+0x00007FFFFFFFFFFF(127TB)//..//..//..//+--------------------------------+0x0000500000000000(80TB)//|RemappedView|//+--------------------------------+0x0000400000000000(64TB)//..//+--------------------------------+0x0000300000000000(48TB)//|Marked1View|//+--------------------------------+0x0000200000000000(32TB)//|Marked0View|//+--------------------------------+0x0000100000000000(16TB)//..//+--------------------------------+0x0000000000000000////64444//387430//+------------------+----+-------------------------------------------------+//|0000000000000000|1111|11111111111111111111111111111111111111111111|//+------------------+----+-------------------------------------------------+//|||//||*43-0ObjectOffset(44-bits,16TBaddressspace)//||//|*47-44MetadataBits(4-bits)0001=Marked0(Addressview16-32TB)//|0010=Marked1(Addressview32-48TB)//|0100=Remapped(Addressview64-80TB)//|1000=Finalizable(AddressviewN/A)//|//*63-48Fixed(16-bits,alwayszero)//ZGC 指针布局有三种方式，分别用于支持 4TB、8TB、16TB 的堆空间，以上代码用于为 layout 3 支持 16TB 的布局；43-0 bit 对象地址；47-44 对象视图，分为三种对象视图：Marked0、Marked1Remappedx86 和 aarch64 架构下最多仅支持 48 位指针，主要是因为硬件限制。通常为了节约成本，64 位处理器地址线一般仅 40-50 条，因此寻址范围远不及 64 位的理论值。多视图ZGC 将同一段物理内存映射到 3 个不同的虚拟内存视图，分别为 Marked0、Marked1、Remapped，这即是 ZGC 中的 Color Pointers，通过 Color Pointers 区分不同的 GC 阶段。映射ZGC 的多视图映射依赖于内核提供的 mmap 方法，具体代码如下zPhysicalMemory.hpp, zPhysicalMemory.cpp, zPhysicalMemoryBacking_linux.cpp//物理内存管理类classZPhysicalMemory{private:ZArray_segments;voidinsert_segment(intindex,uintptr_tstart,size_tsize,boolcommitted);voidreplace_segment(intindex,uintptr_tstart,size_tsize,boolcommitted);voidremove_segment(intindex);public:ZPhysicalMemory();ZPhysicalMemory(constZPhysicalMemorySegment&segment);ZPhysicalMemory(constZPhysicalMemory&pmem);constZPhysicalMemory&operator=(constZPhysicalMemory&pmem);boolis_null()const;size_tsize()const;intnsegments()const;constZPhysicalMemorySegment&segment(intindex)const;voidadd_segments(constZPhysicalMemory&pmem);voidremove_segments();voidadd_segment(constZPhysicalMemorySegment&segment);boolcommit_segment(intindex,size_tsize);booluncommit_segment(intindex,size_tsize);ZPhysicalMemorysplit(size_tsize);ZPhysicalMemorysplit_committed();};//将三个虚拟内存视图映射到同一物理内存//在JDK14中增加了对于ZVerifyViewsJVM参数的支持（https://bugs.openjdk.java.net/browse/JDK-8232604）voidZPhysicalMemoryManager::map(uintptr_toffset,constZPhysicalMemory&pmem)const{constsize_tsize=pmem.size();if(ZVerifyViews){//Mapgoodviewmap_view(ZAddress::good(offset),pmem);}else{//Mapallviewsmap_view(ZAddress::marked0(offset),pmem);map_view(ZAddress::marked1(offset),pmem);map_view(ZAddress::remapped(offset),pmem);}nmt_commit(offset,size);}voidZPhysicalMemoryManager::map_view(uintptr_taddr,constZPhysicalMemory&pmem)const{size_tsize=0;//逐个映射物理内存//ZGC中使用segment管理物理内存，后续文章将详细介绍for(inti=0;iZPageSizeSmall){//EnablemediumpagesZPageSizeMedium=size;ZPageSizeMediumShift=log2_intptr(ZPageSizeMedium);ZObjectSizeLimitMedium=ZPageSizeMedium/8;ZObjectAlignmentMediumShift=(int)ZPageSizeMediumShift-13;ZObjectAlignmentMedium=1<alloc_object(size);}returnaddr;}分配大对象时，触发分配 large page；对齐大对象 size 到 2MB 的倍数后分配 large page。zObjectAllocator.cppuintptr_tZObjectAllocator::alloc_object(size_tsize,ZAllocationFlagsflags){if(sizealloc_page(type,size,flags);if(page!=NULL){//增加使用内存数Atomic::add(_used.addr(),size);}returnpage;}zPageAllocator.cppZPage*ZPageAllocator::alloc_page(uint8_ttype,size_tsize,ZAllocationFlagsflags){EventZPageAllocationevent;retry:ZPageAllocationallocation(type,size,flags);//从pagecache分配page//如果分配成功，调用alloc_page_finalize完成分配//分配过程中，如果是阻塞模式，有可能在安全点被阻塞if(!alloc_page_or_stall(&allocation)){//OutofmemoryreturnNULL;}//如果从pagecache分配失败，则从物理内存申请页//提交pageZPage*constpage=alloc_page_finalize(&allocation);if(page==NULL){//如果commit或者map失败，则goto到retry，重新分配alloc_page_failed(&allocation);gotoretry;}//...//...//...returnpage;}boolZPageAllocator::alloc_page_or_stall(ZPageAllocation*allocation){{//分配page需要上锁，因为只有一个堆ZLockerlocker(&_lock);//分配成功，返回trueif(alloc_page_common(allocation)){returntrue;}//如果是非阻塞模式，返回falseif(allocation->flags().non_blocking()){returnfalse;}//分配请求入队，等待GC完成_stalled.insert_last(allocation);}returnalloc_page_stall(allocation);}//阻塞分配，等待GCboolZPageAllocator::alloc_page_stall(ZPageAllocation*allocation){ZStatTimertimer(ZCriticalPhaseAllocationStall);EventZAllocationStallevent;ZPageAllocationStallresult;//检查虚拟机是否已经完成初始化check_out_of_memory_during_initialization();do{//启动异步GCZCollectedHeap::heap()->collect(GCCause::_z_allocation_stall);//挂起，等待GC结果result=allocation->wait();}while(result==ZPageAllocationStallStartGC);//...//...//...return(result==ZPageAllocationStallSuccess);}阻塞分配与非阻塞分配，由系统参数 ZStallOnOutOfMemory 控制，默认阻塞分配。阻塞分配时，如果分配失败，则触发 GC，等待 GC 结束后再次分配，直到分配成功。对象分配自从 JDK10 中的引入了 JEP 304: Garbage Collector Interface 后，OpenJDK 定义了一整套关于 GC 的虚方法，供具体的 GC 算法实现。极大了简化了开发难度和代码的可维护性。JEP 304 定义了 CollectedHeap 类，每个 GC 都需要实现。CollectedHeap 类负责驱动 HotSpot 的 GC，以及和其他模块的交互。GC 应当实现如下功能：CollectedHeap 的子类；BarrierSet 集合类的实现，提供在运行时各种屏障功能；CollectorPolicy 类的实现；GCInterpreterSupport 的实现，提供 GC 在解释执行时各种屏障功能（使用汇编指令）；GCC1Support 的实现，提供 GC 在 C1 编译代码中各种屏障功能；GCC2Support 的实现，提供 GC 在 C2 编译代码中各种屏障功能；最终 GC 指定参数的初始化；一个 MemoryService，提供内存池、内存管理等。通常地，对象分配的入口在 InstanceKlass::allocate_instance，该方法调用 heap->obj_allocate()进行分配。instanceOopInstanceKlass::allocate_instance(TRAPS){boolhas_finalizer_flag=has_finalizer();//QuerybeforepossibleGCintsize=size_helper();//Querybeforeforminghandle.instanceOopi;i=(instanceOop)Universe::heap()->obj_allocate(this,size,CHECK_NULL);if(has_finalizer_flag&!RegisterFinalizersAtInit){//对于实现了finalize方法的类的实例的特殊处理i=register_finalizer(i,CHECK_NULL);}returni;}CollectedHeap 对象分配流程图对象分配一般遵循如下流程：源码分析ZCollectedHeapZCollectedHeap 重载了 CollectedHeap 的方法，其中包含了对象分配的相关方法。而核心逻辑在放在 ZHeap 中。ZCollectedHeap 中主要的成员方法如下：classZCollectedHeap:publicCollectedHeap{friendclassVMStructs;private://软引用清理策略SoftRefPolicy_soft_ref_policy;//内存屏障，解释执行/C1/C2执行时对象访问的屏障ZBarrierSet_barrier_set;//初始化逻辑ZInitialize_initialize;//堆管理的核心逻辑，包括对象分配、转移、标记ZHeap_heap;//垃圾回收线程，触发ZDirector*_director;//垃圾回收线程，执行ZDriver*_driver;//垃圾回收线程，统计ZStat*_stat;//工作线程ZRuntimeWorkers_runtime_workers;}ZHeapZHeap 是 ZGC 内存管理的核心类。主要变量如下：classZHeap{friendclassVMStructs;private:staticZHeap*_heap;//工作线程ZWorkers_workers;//对象分配器ZObjectAllocator_object_allocator;//页面分配器ZPageAllocator_page_allocator;//页表ZPageTable_page_table;//转发表，用于对象迁移后的指针映射ZForwardingTable_forwarding_table;//标记管理ZMark_mark;//引用处理器ZReferenceProcessor_reference_processor;//弱引用处理器ZWeakRootsProcessor_weak_roots_processor;//转移管理器，用于对象迁移（类比G1的疏散）ZRelocate_relocate;//转移集合ZRelocationSet_relocation_set;//从元空间卸载类ZUnload_unload;ZServiceability_serviceability;}对象分配器对象分配的主要逻辑在 ZObjectAllocator。对象分配器主要变量ZObjectAllocator 的主要变量如下：classZObjectAllocator{private:constbool_use_per_cpu_shared_small_pages;//分CPU记录使用内存sizeZPerCPU_used;//分CPU记录undo内存sizeZPerCPU_undone;//缓存行对齐的模板类ZContended_shared_medium_page;//按CPU从缓存分配对象ZPerCPU_shared_small_page;}分配方法对象分配的核心方法是 alloc_objectuintptr_tZObjectAllocator::alloc_object(size_tsize,ZAllocationFlagsflags){if(sizealloc_object(size);}returnaddr;}small page 分配和 medium page 分配都会调用到 alloc_object_in_shared_page 方法；小对象和中对象的分配略有不同，小对象是根据所在 CPU 从共享页面中分配对象。而中对象则是全部线程共享一个 medium page。// shared_page：页面地址// page_type：page类型，small还是medium//page_size:pagesize//size:对象size//flags:分配标识uintptr_tZObjectAllocator::alloc_object_in_shared_page(ZPage**shared_page,uint8_tpage_type,size_tpage_size,size_tsize,ZAllocationFlagsflags){uintptr_taddr=0;//获取一个pageZPage*page=Atomic::load_acquire(shared_page);if(page!=NULL){//调用page的分配对象方法addr=page->alloc_object_atomic(size);}if(addr==0){//如果刚才没有获取page成功，则分配一个newpageZPage*constnew_page=alloc_page(page_type,page_size,flags);if(new_page!=NULL){//先分配对象，然后加载page到shared_page缓存addr=new_page->alloc_object(size);retry://加载page到shared_page缓存ZPage*constprev_page=Atomic::cmpxchg(shared_page,page,new_page);if(prev_page!=page){if(prev_page==NULL){//如果prev_page已经淘汰，则goto到retry一直重试page=prev_page;gotoretry;}//其他线程加载了页面，则使用prev_page分配constuintptr_tprev_addr=prev_page->alloc_object_atomic(size);if(prev_addr==0){//如果分配失败，则goto到retry一直重试page=prev_page;gotoretry;}addr=prev_addr;undo_alloc_page(new_page);}}}returnaddr;}Page 内的对象分配page 内的对象分配主要是两个方法 alloc_object_atomic 和 alloc_object，其中 alloc_object 没有锁竞争，主要用于新 page 的第一次对象分配。先看 alloc_object_atomicinlineuintptr_tZPage::alloc_object_atomic(size_tsize){assert(is_allocating(),"Invalidstate");//对象对齐，默认8字节对齐constsize_taligned_size=align_up(size,object_alignment());uintptr_taddr=top();for(;;){constuintptr_tnew_top=addr+aligned_size;if(new_top>end()){//page没有申昱空间，则返回0return0;}//cas操作更新prev_top指针constuintptr_tprev_top=Atomic::cmpxchg(&_top,addr,new_top);if(prev_top==addr){//调用ZAddress::good获取coloredpointerreturnZAddress::good(addr);}//无限重试addr=prev_top;}}再看看 alloc_objectinlineuintptr_tZPage::alloc_object(size_tsize){assert(is_allocating(),"Invalidstate");//对象空间对齐，默认8字节constsize_taligned_size=align_up(size,object_alignment());constuintptr_taddr=top();constuintptr_tnew_top=addr+aligned_size;if(new_top>end()){//剩余空间不足，返回0return0;}_top=new_top;//调用ZAddress::good获取coloredpointerreturnZAddress::good(addr);}Colored pointer 的计算可以看到上述两个方法在分配结束都调用了 ZAddress::good 返回 colored pointer。看看 ZAddress::good 的实现。inlineuintptr_tZAddress:ffset(uintptr_tvalue){returnvalue&ZAddressOffsetMask;}inlineuintptr_tZAddress::good(uintptr_tvalue){returnoffset(value)|ZAddressGoodMask;}voidZAddress::set_good_mask(uintptr_tmask){ZAddressGoodMask=mask;ZAddressBadMask=ZAddressGoodMask^ZAddressMetadataMask;ZAddressWeakBadMask=(ZAddressGoodMask|ZAddressMetadataRemapped|ZAddressMetadataFinalizable)^ZAddressMetadataMask;}good 方法其实挺简单，先取 4 位染色值，然后或操作实际地址，获取 colored pointer。colored pointer 将在 load barrier 中使用，后文将详细介绍 load barrier 机制。读屏障对于并发 GC 来说，最复杂的事情在于 GC worker 在标记-整理，而 Java 线程(Mutator)同时还在不断的创建新对象、修改字段，不停的更新对象引用关系。因此并发 GC 一般采用两种策略 Incremental Update(增量更新、CMS) 和 SATB(snapshot at beginning、G1) ，两种策略网上介绍文章很多，此处不再赘述。SATB 重点关注引用关系的删除，可以参考我之前的博客JVM G1 源码分析（四）- Dirty Card Queue Set（https://blog.csdn.net/a860MHz/article/details/97631300），而 Incremental Update 重点关注引用关系的增加。而 ZGC 并没有采取类似方式，而是借助读屏障、colored pointer 来实现并发标记-整理。原理什么是 Load Barrier一小段在最佳位置由 JIT 注入的代码从堆中加载一个对象引用时检查这个引用是否是 bad color如果是，则自愈Load Barrier 的触发从堆中加载对象引用时触发 load barrier。//从堆中加载一个对象引用，需要loadbarrierStringn=person.name;//不需要loadbarrier，不是从堆中加载Stringp=n;//不需要loadbarrier，不是从堆中加载n.isEmpty();//不需要loadbarrier，不是引用类型intage=person.age;当引用类型 n 被赋值修改后，在下一次使用 n 前，会测试 n 的染色指针是否为 good。此时测试为 bad color 可知 n 的引用地址进行过修改，需要自愈。触发 load barrier 的伪代码如下：//从堆中加载一个对象引用，需要loadbarrierStringn=person.name;if(n&bad_bit_mask){slow_path(register_for(n),address_of)}对应的汇编代码：//Stringn=person.name;mov0x10(%rax),%rbx//是否badcolortest%rbx,(0x16)%r15//如是，进入slowpathjnzslow_path源码分析掩码zGlobals.hpp////Good/Badmaskstates//--------------------////GoodMaskBadMaskWeakGoodMaskWeakBadMask//--------------------------------------------------------------//Marked0001110101010//Marked1010101110001//Remapped100011100011////Good/badmasksexternuintptr_tZAddressGoodMask;externuintptr_tZAddressBadMask;externuintptr_tZAddressWeakBadMask;zAddress.inline.hppinlineboolZAddress::is_null(uintptr_tvalue){returnvalue==0;}inlineboolZAddress::is_bad(uintptr_tvalue){returnvalue&ZAddressBadMask;}inlineboolZAddress::is_good(uintptr_tvalue){return!is_bad(value)&!is_null(value);}从以上两段代码可以很清晰看出，colored pointer 的状态是 Good/WeakGood/Bad/WeakBad 由 GoodMask 及 BadMask 来测定。同时，GoodMask、BadMask 由 GC 所处的阶段决定。voidZAddress::set_good_mask(uintptr_tmask){ZAddressGoodMask=mask;ZAddressBadMask=ZAddressGoodMask^ZAddressMetadataMask;ZAddressWeakBadMask=(ZAddressGoodMask|ZAddressMetadataRemapped|ZAddressMetadataFinalizable)^ZAddressMetadataMask;}voidZAddress::initialize(){ZAddressOffsetBits=ZPlatformAddressOffsetBits();ZAddressOffsetMask=(((uintptr_t)1<