JVM剖析系列：深入理解锁合并优化

需积分: 10 98 浏览量更新于2024-07-19 收藏 19.4MB PDF 举报

"JVM-Anatomy Park 是一系列深入探讨 JVM 内部工作机制的文章合集，由 Aleksey Shipilev 编写，他是 Red Hat OpenJDK 团队的 Performance Geek。这些文章以浅显易懂的方式讲解每个主题，平均每篇大约需要花费 5-10 分钟阅读，旨在提供对 JVM 深入理解的见解，但需注意的是，内容并非经过全面审查，可能存在主观性、错误或不一致性，使用时需自行承担风险。文章系列关注的领域包括但不限于逃逸分析（Escape Analysis）和锁合并（Lock Coarsening）优化，这两者是 HotSpot 虚拟机性能优化的重要组成部分。逃逸分析是一种编译时的技术，用于判断对象是否能逃出方法范围，从而决定对象在栈上分配还是堆上分配，以减少垃圾回收的压力。而锁合并则是为了减少因频繁琐碎的锁操作带来的性能损耗，它会合并相邻的锁定块，使得并发控制更为高效。在 Jav

Runningwithexperimental"no-op"EpsilonGC (http://openjdk.java.net/jeps/318)canhelptoestimateGCoverheadswhenno

collectorisrunningatall.Here,wecanﬁtexactlyin4GBpre-sizedheap,andapplicationrunswithnopauses

whatsoever.Itwouldnotsurviveanythingmoreactivelymutatingtheheap,though.Noticethat"real"and"user"+"sys"

timesarealmostequal,whichcorroboratesthetheorytherewasasingleapplicationthreadonly.

DifferentGCshavedifferenttradeoffsintheirimplementations.BrushingtheGCoffas"badidea"isastretch.Choosea

collectorforyourkindofworkload,byunderstandingyourworkload,availableGCimplementations,andyour

performancerequirements.EvenifyouchoosetotargetplatformswithoutGCs,youwouldstillneedtoknow(and

choose!)yournativememoryallocators.Whenrunningexperimentalworkloads,trytounderstandwhattheytellyou,

andlearnfromthat.Peace.

Dotheseplaytogetheratall?

WhatisTLABallocation?Pointer-bumpallocation?Whoisresponsibleforallocatingobjectsanyway?

Mostofthetimewedo ,theruntimeenvironmenthastoallocatestoragefortheinstanceinquestion.

ThetextbookGC(memorymanager)interfaceforallocationisverysimple:

Ofcourse,sincememorymanagersareusuallywritteninthelanguagedifferentfromthelanguageruntimeistargeted

by(e.g.JavatargetsJVM,yetHotSpotJVMiswritteninC++),theinterfacegetsmurkier.Forexample,suchacallfrom

JavaprogramneedstotransitintonativeVMcode.Doesitcostmuch?Probably.Doesthememorymanagerhastocope

withmultiplethreadsbeggingformemory?Forsure.

Sotooptimizethis,wemayinsteadallowthreadstoallocatetheentire ofmemoryfortheirneeds,andonlytransit

toVMtogetanewblock.InHotspot,theseblocksarecalledThreadLocalAllocationBuffers(TLABs),andthereisa

sophisticatedmachinerybuilttosupportthem.NoticethatTLABsarethread-localinthetemporalsense,meaningthey

actlikethebufferstoacceptcurrentallocations.TheystillarepartsofJavaheap,thethreadcanstillwritethereference

toanewlyallocatedobjectintotheﬁeldoutsideofTLAB,etc.

AllknownOpenJDKGCssupportTLABallocation.ThispartofVMcodeisprettywellsharedamongthem.AllHotspot

compilerssupportTLABallocation,soyouwouldusuallyseethegeneratedcodeforobjectallocationlikethis:

Theallocationpathisinlinedinthegeneratedcode,andassuchdoesnotrequirecallingintoGCtoallocatetheobject.If

wearerequestingtoallocatetheobjectthatdepletestheTLAB,ortheobjectsislargeenoughtoneverﬁtintotheTLAB,

thenwetakea"slowpath",andeithersatisfytheallocationthere,orcomebackwithafreshTLAB.Noticehowthemost

frequent"normal"pathis addingtheobjectsizetoTLABcurrentcursor,andthenmovingon.

Thisiswhythisallocationmechanismissometimescalled .Pointerbumprequiresacontiguous

chunkofmemorytoallocateto,though — whichbringsbacktheneedforheapcompaction.NoticehowCMSdoesfree-

listallocationin"old"generation,thusenablingconcurrentsweep,butithascompactingstop-the-world"young"

collections,thatbeneﬁtfrompointerbumpallocation!Amuchlowerquantityofobjectsthatsurvivedtheyoung

collectionwouldpaythecostoffreelistallocation.

Forthesakeofexperiment,wecanturnTLABmachineryoffwith .Then,allallocationswouldtakeinto

thenativemethod,likethis:

…but,asyouwouldseebelow,itisusuallyabadidea.

Asusual,letustrytoconstructanexperimenttoseeTLABallocationinaction.SincethemachineryissharedbyallGC

implementationsthere,inmakessensetominimizetheimpactofotherpartsofruntimebyusingexperimentalEpsilon

GC (http://openjdk.java.net/jeps/8174901).Indeed,itimplementsallocation ,andthusprovidesagoodresearchvesselfor

thiswork.

Quicklydraftingaworkload:allocating50Mobjects(whynot?),andrunningwithJMHwithSingleShotmodetoget

statisticsandproﬁlingforfree.Youcoulddothiswithastandalonetesttoo,butSingleShotisjusttooconvenienthere.

Thistestallocates50Mobjectsinasinglethread.Thisisempiricallyselectedtomake20GBheaplastforatleast6

iterations,aswewouldseenext.Theexperimental optionisusedtocontroltheTLABsizing

exactly.OtherOpenJDKGCssharethe TLABsizing

(https://blogs.oracle.com/daviddetlefs/entry/tlab_sizing_an_annoying_little)policythatselectsthesizesbasedonallocationpressure

andotherconcerns.ForourperformancetestsitiseasiertonailtheTLABsize.

Withoutfurtherado,thesearetheresults:

Noticehowweareabletopulloff2.5GB/secallocationrateinasinglethread.With16byteobjects,thismeans160

millionobjectspersecond.Inmulti-threadedworkloads,theallocationratesmayreachtensofgigabytespersecond.Of

course,onceTLABsizegetssmaller,boththeallocationcostsgoup,andallocationrategoesdown.Unfortunately,we

剩余80页未读，继续阅读

加菲也烦恼

粉丝: 1
资源: 11

JVM剖析系列：深入理解锁合并优化

nginx-upstream-jvm-route-1.15

nginx-upstream-jvm-route 和 nginx 对应版本，亲测可用

echo > jvm - portals.log

jvm-sandbox-repeater

spring-boot.run.jvm-arguments 配置介绍

jvm-sandbox

JVM - 双亲委派机制

spring-boot.run.jvm-arguments 怎么配置

jvm -Xms -Xmx -XX:PermSize -XX:MaxPermSize 设置比例

jvm-pager是什么

最新资源