4. JVM Memory
We’re looking at the JVM heap memory from
now on!
. This is where your objects and classes are
being held while the JVM is running
. Basic assumption: lots of short-lived objects,
few long-lived objects
. Note: even local objects within a method
end up on the heap
6. Heap management
For the JVM it’s impossible to know in
advance how your a certain object will live.
. Solution is a generational management
..Young Generation (Eden, Survivor Spaces)
.. Tenured/Old Generation
.. Permanent Generation
7.
8. Young Generation
Every single newly created object is created
here.
. In general: GC in the YG should happen
often and shouldn’t take long
. If an object survives a certain number of GC
in the YG the JVM assumes that the object is
long-lived -> moved into Old Generation
9.
10. Old Generation
The Old Generation fills up more and more
and at some stage there will be a GC
happening in there
. Often the OldGen is much larger than the
YG -> GC might take long(er)
. GC stop the JVM - big problem if your
OldGen GC takes multiple seconds
11.
12. Further issues
If one is short on operating system memory
and (parts of) the JVM is in Swap Space, a GC
in the OldGen can take minutes.
. Always make sure that the JVM fits into the
main memory of the server
. Rule of thumb: Avoid OldGen GCs
whenever you can!
13. Typical examples
short-lived:
. Local variables/objects, iterators in a loop
etc
medium-lived:
. Session-based information
long-lived:
. Thread pools, singletons, frameworks
15. Why is that good?
Where there is lots of garbage, cleaning up
the garbage fast is really worthwhile
. Cleaning up the YG often means we have
space for new, fresh objects
. The GC doesn’t have to search the whole
heap for unused objects but just a certain
generation at a time
. Objects die appropriately
17. Permanent Generation
PermGen
. Class objects, internal JVM objects, JIT
information
. Urban myth: It’s not part of the “real” heap -
so you don’t have to worry.
19. YG internals
The YG consists of Eden and two Survivor
spaces
. new/newInstance() create objects in Eden (if
an object is larger than Eden it will be
created in the OldGen)
. One Survivor space is always empty, during
YG GC the JVM will copy survivors in Eden
and S1 to S2 and vice versa
20.
21. OldGen internals
The amount of survived GCs is called
Tenuring Threshold -> “Promotion”
. Note: Sometimes objects get promoted to
OldGen because Survivor spaces are too
small
Alternatives: Have one GC for the whole
heap. Efficiency?
22. Selecting a GC
With YG and OldGen being dealt with
separately we can now further select
different GC algorithms. Factors:
. Efficiency/Throughput
. Pauses and Concurrency
. Overhead
23. How to choose?
Depends on the JVM...
. Sun’s Java 5/6 JVM comes pre-setup with
certain criteria for selecting GC strategies
and settings (“Ergonomics”) - most can be
changed
. JRockit / Apple JVMs similar
24. YG Collectors
. Mark-and-Sweep: Marking phase to get all
“reachable” objects, sweeping phase cleans
heap.
. Problem: fragmentation and issues when
allocating new memory
. Note: I have seen cases where
fragmentation led to out-of-memory issues
25. YG Collectors
. Mark-and-Copy: Marking phase to get all
“reachable” objects, copy those into a new
area
. No fragmentation, but extra scavenging
phase, JVM holds slightly more memory than
needed
. Lends itself to the E+S1+S2 concept
26. InterGen Reference
There is extra effort involved to keep track
of references from OldGen to YG.
. Card Tables, Dirty Markers etc
27. Parallel GC in the YG
Mark-and-Copy is “Stop-The-World”-GC
. Single Reaper-Thread
. Since Java 1.4.2 we have a Parallel GC in the
YG, there is still a “Stop-The-World” pause,
but it’s much shorter!
. Default YG GC since Java 5 if machine has
multiple cores or CPUs
28. Parallel GC in the YG
Some JVM args
-XX:+UseParallelGC
-XX:ParallelGCThreads=<n>
29. OldGen Collectors
Lots of objects, low mortality - Mark-and-
Copy would be inefficient: Mark-and-
Compact
.Variation of Mark-and-Sweep (reduced
fragmentation)
. Quite involved: Marking, Calculation of new
locations, Reference Adjustments, Moving
30. OldGen Collectors
Mark-and-Compact is expensive if we have
lots of surviving objects and if we have a
large heap
. Big downside: serial collector - stops all
threads
32. Default selections
. OldGen: Since Java 6 parallel Mark-and-
Compact is default on server profiles (use
JVM args in Java 5 and client profiles)
.YG: Since Java 5 parallel Mark-and-Copy is
default on server profiles (use JVM args in
Java 1.4.x and client profiles)
33. Some thoughts
. Concurrent Mark-and-Sweep is the
preferred OldGen collector if you want to
avoid “Stop-The-World” collections by all
means.
. Overall throughput slightly less than the
parallel Mark-and-Compact collector, but
much better suited for web apps
. Well suited for large heaps (actually you
need large heaps for CMS)
34.
35. Memory sizing
Initial and maximum heap size:
-Xms6144m, -Xmx6144m
PermGen size:
-XX:MaxPermSize=256m
YG size:
-XX:NewSize=2500m, -XX:MaxNewSize=2500m
37. GC Tuning
. Make assumptions for load, memory sizing
and GC settings
. Run load tests, Monitor, Measure
. Use tools: Fusion Reactor, GCViewer,
VisualGC etc.
. Learn, change one setting and repeat cycle
38. GC Tuning
. GC Throughput: 95%+ are seen as good. In a
web app environment I don’t like anything
below 97%
. Go for pause tuning if GC pauses are an
issue
. Memory is usually not an issue anymore in
today’s 64-bit world, be aware of 64-bit
overhead though
39. Overview
Max throughput Min pause time
2+ cores 1/2 cores 2+ cores 1/2 cores
YG par YG ser YG par YG ser YG
OldGen par OG ser OG CMS
-XX: -XX:
JVM Flag +UseParallelGC +UseSerialGC
-XX:+UseConcMarkSweepGC
