Java runtime environment abstracts memory management (allocation and deallocation for object in the heap) on behalf of programmers. This allows programmers to focus more on the real work and let Java Virtual Machine (JVM) manage the lifecycle of objects. Garbage Collector is given the job of reclaiming (or collecting) memory from the objects which are no longer referenced (i.e. it frees memory from the objects which are no longer in use).
This post, I will briefly cover the overview of GC cycle and it's implication on the running application.
GC overview
When GC kicks in, it starts from the Root object and visits all the live objects. Objects which are reachable through this chain are active objects so the remaining objects are candidates for getting garbage collected. Reference counting collector and tracing collector are few popular types of GC algorithms.
GC has below two mandates:
- Free up unreferenced memory so that apps allocation request for new objects can be honored without running out of memory
- Reclaim unreferenced memory with minimum impact to the performance (i.e. latency, throughput) of running app
If JVM doesn't run GC cycle enough, the app will run out of memory. And if it runs GC cycle too frequently, the app will loose on throughput and response time.
In short, GC is a double-edged sword.
What enables GC cycle
Predicting exact time of GC is incredibly difficult. JVM specification doesn't guarantee any behavior and hence all vendors are free to implement it in their own custom way. Specification just says, that, if an object needs to get allocated memory and there is not enough free memory in the heap for allocation then application should throw OutOfMemory error. I have listed below few pointers on what leads to GC:
Steps which lead to GC:
- Memory allocating thread doesn't find large enough consecutive memory for the object it wants to allocate
- JVM thread notifies to the GC of above problem
- GC determines if it's safe to start a GC cycle
- It is safe to start GC when all active application threads are at safe points(i.e. GC cycle will not cause any issue to running application)
- GC kicks in
Be careful that the decision making algorithm is not so trivial as discussed above, but it gives fair idea of what may lead to a GC cycle. As a programmer/administrator you can't do much (unless you use your own custom GC library). But, Java gives few technique which can be used to request GC.
You can call below method(s) to request full garbage collection cycle.
System.gc() or
Runtime.getRuntime.gc()
Out of application:
You can request GC cycle though jconsole as shown below (jconsole provides a button to request GC)
Both approaches are one and the same. It suggests/request that, GC should try recycling unused objects in order to free the memory they currently occupy. This is just a hint or request to GC; GC has all rights to ignore the request.
References:
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html
Related Articles
No comments:
Post a Comment