4.
JVM MemoryWe’re looking at the JVM heap memory fromnow on!. This is where your objects and classes arebeing held while the JVM is running. Basic assumption: lots of short-lived objects,few long-lived objects. Note: even local objects within a methodend up on the heap

7.
Young GenerationEvery single newly created object is createdhere.. In general: GC in the YG should happenoften and shouldn’t take long. If an object survives a certain number of GCin the YG the JVM assumes that the object islong-lived -> moved into Old Generation

8.
Old GenerationThe Old Generation ﬁlls up more and moreand at some stage there will be a GChappening in there. Often the OldGen is much larger than theYG -> GC might take long(er). GC stop the JVM - big problem if yourOldGen GC takes multiple seconds

9.
Further issuesIf one is short on operating system memoryand (parts of) the JVM is in Swap Space, a GCin the OldGen can take minutes.. Always make sure that the JVM ﬁts into themain memory of the server. Rule of thumb: Avoid OldGen GCswhenever you can!

12.
Why is that good?Where there is lots of garbage, cleaning upthe garbage fast is really worthwhile. Cleaning up the YG often means we havespace for new, fresh objects. The GC doesn’t have to search the wholeheap for unused objects but just a certaingeneration at a time. Objects die appropriately

16.
YG internalsThe YG consists of Eden and two Survivorspaces. new/newInstance() create objects in Eden (ifan object is larger than Eden it will becreated in the OldGen). One Survivor space is always empty, duringYG GC the JVM will copy survivors in Edenand S1 to S2 and vice versa

17.
OldGen internalsThe amount of survived GCs is calledTenuring Threshold -> “Promotion”. Note: Sometimes objects get promoted toOldGen because Survivor spaces are toosmallAlternatives: Have one GC for the wholeheap. Efﬁciency?

18.
Selecting a GCWith YG and OldGen being dealt withseparately we can now further selectdifferent GC algorithms. Factors:. Efﬁciency/Throughput. Pauses and Concurrency. Overhead

23.
Parallel GC in the YGMark-and-Copy is “Stop-The-World”-GC. Single Reaper-Thread. Since Java 1.4.2 we have a Parallel GC in theYG, there is still a “Stop-The-World” pause,but it’s much shorter!. Default YG GC since Java 5 if machine hasmultiple cores or CPUs

33.
GC Tuning. GC Throughput: 95%+ are seen as good. In aweb app environment I don’t like anythingbelow 97%. Go for pause tuning if GC pauses are anissue. Memory is usually not an issue anymore intoday’s 64-bit world, be aware of 64-bitoverhead though