Garbage Collection
Garbage Collection = Object Promotion (Copy phase) + Marking (Compact MArk and Sweep) for collection
In JDK 6 there are three types of garbage collectors:
Serial Collector - Single Threaded.
Entire Garbage collection is done in one thread. Its suitable in 1 cpu machine.
Garbage Collections throughput in a multi-cpu machine is very low.
Parallel Collector - Garbage Collection is multi-threaded. You can specify the number of threads.
Default value is the number of CPUs. Improves the GC times and throughput as compared to a Serial collector in a multi-cpu machine.
The idea is the Application is completely halted when GC is running. This is stop-the-world-garbage collector
Use this when your app can afford to pause for high times. This will allow the Application to give more throughput. This may not give lowest latency but gives highest throughput since cpu is available 100% until GC.
CMS Collector - Garbage Collection is multi-threaded. You can specify the number of threads.
Default value is the number of CPUs. Improves the GC times and throughput as compared to a Serial collector in a multi-cpu machine.
Concurrent Mark and Sweep. - mark phase and sweep phase.
The idea is this runs concurrently with the app. Mark phase uses very less cpu.
Sweep phase is the time consuming.
Use this when your app wants low latency and cannot afford big pauses or no down-times or very low to 0 response times are needed from the app.
This will not give highest throughput since since cpu is also engaged in the concurrent GC threads.
Java Heap
Objects are first allocated on the Eden space. They are promoted from Eden space to S1 then to S2 and then to Old Gen.
Eden -> S1
This is relatively very fast. There is no real promotion?
Young Gen => Old Gen when there is no allocation space left on Young.
When Old Gen is full and cannot allocate space for objects to be promoted from
Young a Major GC is called.
Major GC = involves object destruction (finalize calls) and memory compaction (arranging the live objects contiguously)
Minor GC = Object Promotion
Young Gen is for allocating the newly created objects.
Young Gen:Old Gen ratio can be specified to the JVM.
Ideally, if you know the behavior of the app then you can determine the objects that are created throughout the life cycle of the app. The ones that live longer or through the life of the app
for e.g. caches etc. the Old Gen should be atleast large enough to accommodate them. For the other transient objects that come and go through the life of the app Knowing their creation behavior and the pattern of how long they live - you can determine how to divide the rest of the space between Young and Old Gen. The goal is to reduce the chances of Major GC calls as much as possible.
Java Heap = Linkedlist of LinkedLists (Object graph limited by Max Heap Size)
Heap Size : Usually Min and Max heap size should be same.
Let the jvm use the entire address space ( requested on startup for the jvm). This will reduce the number of major GC calls initially (when more memory is needed).
Using a smaller Min Heap size will progressively reduce the number of GC calls as the memory requirement grows in size. But the gc calls will be done often initially until all the memory is being used.
Java utilities :
jstack -l <pid>
This C:\>jstack
Usage:
jstack [-l] <pid>
(to connect to running process)
Options:
-l long listing. Prints additional information about locks
-h or -help to print this help message
C:\>jstack -l 292
2012-03-03 17:44:00
Full thread dump Java HotSpot(TM) Client VM (11.0-b15 mixed mode):
"Worker-138" prio=6 tid=0x35c82800 nid=0xb44 in Object.wait() [0x3b1cf000..0x3b1cfb94]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185)
- locked <0x05e10958> (a org.eclipse.core.internal.jobs.WorkerPool)
at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51)
Locked ownable synchronizers:
- None
jmap
C:\>jmap
Usage:
jmap -histo <pid>
(to connect to running process and print histogram of java object heap
jmap -dump:<dump-options> <pid>
(to connect to running process and dump java heap)
dump-options:
format=b binary default
file=<file> dump heap to <file>
Example: jmap -dump:format=b,file=heap.bin <pid>
num #instances #bytes class name
----------------------------------------------
1: 726659 78478288 [C
2: 203312 28493696 <constMethodKlass>
3: 203312 16281656 <methodKlass>
4: 660949 15862776 java.lang.String
5: 328106 15829632 <symbolKlass>
6: 19521 11986408 <constantPoolKlass>
7: 19521 9057120 <instanceKlassKlass>
8: 105091 7067848 [Ljava.lang.Object;
9: 15915 6887008 <constantPoolCacheKlass>
10: 195449 4690776 java.util.HashMap$Entry
11: 23940 4615512 [B
12: 92234 3980584 [I
13: 16914 3962112 [Ljava.util.HashMap$Entry;
14: 51871 3319744 org.eclipse.core.internal.resources.ResourceInfo
15: 28072 2268280 [S
16: 20896 2006016 java.lang.Class
17: 31469 1386112 [[I
18: 17051 1229088 [[C
19: 46687 1120488 org.eclipse.core.internal.dtree.DataTreeNode
20: 28311 992120 [Ljava.lang.String;
21: 38133 915192 java.util.ArrayList
22: 27462 659088 org.eclipse.jface.text.Line
23: 41049 656784 org.eclipse.datatools.sqltools.result.ResultSetRow
24: 38136 610176 java.lang.Integer
25: 14605 584200 java.util.HashMap
26: 12023 577104 org.eclipse.jdt.core.dom.SimpleName
27: 11607 464280 org.eclipse.ui.internal.navigator.extensions.EvalutationReference
28: 13974 447168 java.lang.ref.SoftReference
29: 10908 436320 org.eclipse.jdt.internal.compiler.ast.SingleTypeReference
30: 3882 434784 org.eclipse.swt.graphics.TextLayout$StyleItem
31: 1346 430720 <objArrayKlassKlass>
http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html
http://www.javacodegeeks.com/2012/01/practical-garbage-collection-part-1.html
https://weblogs.java.net/blog/2006/05/04/understanding-weak-references
Garbage Collection = Object Promotion (Copy phase) + Marking (Compact MArk and Sweep) for collection
In JDK 6 there are three types of garbage collectors:
Serial Collector - Single Threaded.
Entire Garbage collection is done in one thread. Its suitable in 1 cpu machine.
Garbage Collections throughput in a multi-cpu machine is very low.
Parallel Collector - Garbage Collection is multi-threaded. You can specify the number of threads.
Default value is the number of CPUs. Improves the GC times and throughput as compared to a Serial collector in a multi-cpu machine.
The idea is the Application is completely halted when GC is running. This is stop-the-world-garbage collector
Use this when your app can afford to pause for high times. This will allow the Application to give more throughput. This may not give lowest latency but gives highest throughput since cpu is available 100% until GC.
CMS Collector - Garbage Collection is multi-threaded. You can specify the number of threads.
Default value is the number of CPUs. Improves the GC times and throughput as compared to a Serial collector in a multi-cpu machine.
Concurrent Mark and Sweep. - mark phase and sweep phase.
The idea is this runs concurrently with the app. Mark phase uses very less cpu.
Sweep phase is the time consuming.
Use this when your app wants low latency and cannot afford big pauses or no down-times or very low to 0 response times are needed from the app.
This will not give highest throughput since since cpu is also engaged in the concurrent GC threads.
Java Heap
| Young Gen | | Old Gen (Perm Gen) | ||
| Eden | Survivor 1 | Survivor 2 | | |
Objects are first allocated on the Eden space. They are promoted from Eden space to S1 then to S2 and then to Old Gen.
Eden -> S1
This is relatively very fast. There is no real promotion?
Young Gen => Old Gen when there is no allocation space left on Young.
When Old Gen is full and cannot allocate space for objects to be promoted from
Young a Major GC is called.
Major GC = involves object destruction (finalize calls) and memory compaction (arranging the live objects contiguously)
Minor GC = Object Promotion
Young Gen is for allocating the newly created objects.
Young Gen:Old Gen ratio can be specified to the JVM.
Ideally, if you know the behavior of the app then you can determine the objects that are created throughout the life cycle of the app. The ones that live longer or through the life of the app
for e.g. caches etc. the Old Gen should be atleast large enough to accommodate them. For the other transient objects that come and go through the life of the app Knowing their creation behavior and the pattern of how long they live - you can determine how to divide the rest of the space between Young and Old Gen. The goal is to reduce the chances of Major GC calls as much as possible.
Java Heap = Linkedlist of LinkedLists (Object graph limited by Max Heap Size)
Heap Size : Usually Min and Max heap size should be same.
Let the jvm use the entire address space ( requested on startup for the jvm). This will reduce the number of major GC calls initially (when more memory is needed).
Using a smaller Min Heap size will progressively reduce the number of GC calls as the memory requirement grows in size. But the gc calls will be done often initially until all the memory is being used.
Java utilities :
jstack -l <pid>
This C:\>jstack
Usage:
jstack [-l] <pid>
(to connect to running process)
Options:
-l long listing. Prints additional information about locks
-h or -help to print this help message
C:\>jstack -l 292
2012-03-03 17:44:00
Full thread dump Java HotSpot(TM) Client VM (11.0-b15 mixed mode):
"Worker-138" prio=6 tid=0x35c82800 nid=0xb44 in Object.wait() [0x3b1cf000..0x3b1cfb94]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185)
- locked <0x05e10958> (a org.eclipse.core.internal.jobs.WorkerPool)
at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51)
Locked ownable synchronizers:
- None
jmap
C:\>jmap
Usage:
jmap -histo <pid>
(to connect to running process and print histogram of java object heap
jmap -dump:<dump-options> <pid>
(to connect to running process and dump java heap)
dump-options:
format=b binary default
file=<file> dump heap to <file>
Example: jmap -dump:format=b,file=heap.bin <pid>
num #instances #bytes class name
----------------------------------------------
1: 726659 78478288 [C
2: 203312 28493696 <constMethodKlass>
3: 203312 16281656 <methodKlass>
4: 660949 15862776 java.lang.String
5: 328106 15829632 <symbolKlass>
6: 19521 11986408 <constantPoolKlass>
7: 19521 9057120 <instanceKlassKlass>
8: 105091 7067848 [Ljava.lang.Object;
9: 15915 6887008 <constantPoolCacheKlass>
10: 195449 4690776 java.util.HashMap$Entry
11: 23940 4615512 [B
12: 92234 3980584 [I
13: 16914 3962112 [Ljava.util.HashMap$Entry;
14: 51871 3319744 org.eclipse.core.internal.resources.ResourceInfo
15: 28072 2268280 [S
16: 20896 2006016 java.lang.Class
17: 31469 1386112 [[I
18: 17051 1229088 [[C
19: 46687 1120488 org.eclipse.core.internal.dtree.DataTreeNode
20: 28311 992120 [Ljava.lang.String;
21: 38133 915192 java.util.ArrayList
22: 27462 659088 org.eclipse.jface.text.Line
23: 41049 656784 org.eclipse.datatools.sqltools.result.ResultSetRow
24: 38136 610176 java.lang.Integer
25: 14605 584200 java.util.HashMap
26: 12023 577104 org.eclipse.jdt.core.dom.SimpleName
27: 11607 464280 org.eclipse.ui.internal.navigator.extensions.EvalutationReference
28: 13974 447168 java.lang.ref.SoftReference
29: 10908 436320 org.eclipse.jdt.internal.compiler.ast.SingleTypeReference
30: 3882 434784 org.eclipse.swt.graphics.TextLayout$StyleItem
31: 1346 430720 <objArrayKlassKlass>
http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html
http://www.javacodegeeks.com/2012/01/practical-garbage-collection-part-1.html
https://weblogs.java.net/blog/2006/05/04/understanding-weak-references
No comments:
Post a Comment