How is the generational collector implemented in HotSpot(tm)?
The default collector in HotSpot has two generations:
1) young generation and the
2) tenured generation.
è Most allocations are done in the young generation. The young generation is optimized for objects that have a short lifetime relative to the interval between collections.
è Objects that survive several collections in the young generation are moved to the tenured generation.
è young generation is typically smaller and is collected more often. The tenured generation is typically larger and collected less often.
young generation collector is a copying collector.
young generation is divided into 3 spaces:
ü eden-space,
ü to-space, and
ü from-space
Allocations are done from eden-space and from-space. When those are full a young generation is collection is done. The expectation is that most of the objects are garbage and any surviving objects can be copied to to-space. If there are more surviving objects than can fit into to-space, the remaining objects are copied into the tenured generation. There is an option to collect the young generation in parallel.
What is the relevance of -XX:MaxNewSize? Where will the differences between -XX:NewSize and -XX:MaxNewSize grow, Eden or Survivor Spaces?
The young generation is set by a policy that bounds the size from below by NewSize and bounds it from above by MaxNewSize. As the young generation grows from NewSize to MaxNewSize, both eden and the survivor spaces grow.
How should the permanent generation be sized?
The permanent generation is used to hold reflective of the VM itself such as class objects and method objects. These reflective objects are allocated directly into the permanent generation, and it is sized independently from the other generations. Generally, sizing of this generation can be ignored because the default size is adequate. However, programs that load many classes may need a larger permanent generation.
How can I increase the permanent generation size?
command line option -XX:MaxPermSize=
How do I know what classes are being loaded or unloaded?
command line options -XX:+TraceClassloading and -XX:+TraceClassUnloading
What is the best size for the young generation?
The young generation should be sized large enough so that short-lived objects have a chance to die before the next young generation collection. This is a tradeoff since a larger young generation will allow more time for objects to die but may also take longer to collect. Experiment with the size of the young generation to optimize the young generation collection time or the applicationthroughput.
What should I do if my application has mid- or long-lived objects?
Objects that survive a young generation collection have a copying cost (part of the algorithm for a young generation collection is to copy any objects that survive). Mid- or long-lived objects may be copied multiple times.
Use the -XX option MaxTenuringThreshold to determine the copying costs.
Use -XX:MaxTenuringThreshold=0 to move an object that survives a young generation collection immediately to the tenured generation. If that improves the performance of the application, the copying of long-lived objects is significant. Note that the throughput collector does not use the MaxTenuringThreshold parameter.
What type of collection does a System.gc() do?
An explicit request to do a garbage collection does a full collection (both young generation and tenured generation).
A full collection is always done with the application paused for the duration of the collection.
What is the Concurrent Mark Sweep (CMS) collector?
The Concurrent Mark Sweep (CMS) collector (or concurrent low pause collector) collects the tenured generation. It attempts to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads.
What are the phases of the concurrent low pause collector?
There are six phases involved in the collection:
Phase 1 (Initial Checkpoint) involves stopping all the Java threads, marking all the objects directly reachable from the roots, and restarting the Java threads.
Phase 2 (Concurrent Marking) starts scanning from marked objects and transitively marks all objects reachable from the roots. The mutators are executing during the concurrent phases 2, 3, and 5 below and any objects allocated in the CMS generation during these phases (including promoted objects) are immediately marked as live.
Phase 3: During the concurrent marking phase mutators may be modifying objects. Any object that has been modified since the start of the concurrent marking phase (and which was not subsequently scanned during that phase) must be rescanned. Phase 3 (Concurrent Precleaning) scans objects that have been modified concurrently. Due to continuingmutator activity the scanning for modified cards may be done multiple times.
Phase 4 (Final Checkpoint) is a stop-the-world phase. With mutators stopped the final marking is done by scanning objects reachable from the roots and by scanning any modified objects. Note that after this phase there may be objects that have been marked but are no longer live. Such objects will survive the current collection but will be collected on the next collection.
Phase 5 (Concurrent Sweep) collects dead objects. The collection of a dead object adds the space for the object to a free list for later allocation. Coalescing of dead objects may occur at this point. Note that live objects are not moved.
Phase 6 (Resetting) clears data structures in preparation for the next collection.
What is the Parallel Garbage collector (-XX:+UseParallelGC)?
ü The new parallel garbage collector is similar to the young generation collector in the default garbage collector but uses multiple threads to do the collection.
ü By default on a host with N CPUs, the parallel garbage collector uses N garbage collector threads in the collection.
ü The number of garbage collector threads can be controlled with a command line option (see below).
ü On a host with a single CPU the default garbage collector is used even if the parallel garbage collector has been requested.
ü On a host with 2 cpus the Parallel garbage collector generally performs as well as the default garbage collector and a reduction in the young generation garbage collector pause times can be expected on hosts with more than 2 cpus.
What is the Parallel Young Generation collector (-XX:+UseParNewGC)?
The parallel young generation collector is similar to the parallel garbage collector (-XX:+UseParallelGC) in intent and differs in implementation.
Most of the above description for the parallel garbage collector (-XX:+UseParallelGC) therefore applies equally for the parallel young generation collector.
Unlike the parallel garbage collector (-XX:+UseParallelGC) this parallel young generation collector can be used with the concurrent low pause collector that collects the tenured generation.
Java Performance Tuning
What to monitor in OS Level
1) CPU Utilization
2) Network Traffic
3) Disk I/O
4) Virtual Usage Memory usage
5) Process and Kernal Locks
CPU Monitoring
1) High SYS /Kernal CPU time
2) Idle Cpu
- In Multi threaded applications and muticore system idle cpu can be an indicator of an application’s inability to scale.
3) High VCX ( voluntary Context Switching)
Tools for monitoring
1) Vmstat – (solaris & Linux) - Used to obtain Summaries of CPU’s Usage.
2) Task Manager (windows)
light-weight process (LWP)
LWP runs in user space on top of a single kernel thread and shares its address spaceand system resources with other LWPs within the same process.
Network I/O
1) Network Utilization in terms of TCP statistics and established connections
Tools for monitoring
Netstat (solaris and linux)
Monitoring Disk I/o
1) Number of Disk accesses and average Latencies
2) Tools for monitoring
iostat (solaris and linux)
Virtual Memory :Fixing the swapping problem
1) Smaller Java Heap Size
2) Add Physical Memory
3) Reduce number of applications Running on the machine
No comments:
Post a Comment