System.gc() exists as an effort to enforce the JVM to free up some memory.
Abhay wrote: why this method System.gc() is being added in Java API
First of all , any code that is dependent on explicit System.gc() calls is considered broken code and should be avoided at all costs. The gc exists for the JVM and only the JVM should be left responsible to handle it.
Abhay wrote: whether that GC will be Full GC or Minor GC
This is exactly the reason why explicit calls to system.gc() is bad practice because the answer to that question in one line is "You don't know and you will never know". You are completely un-aware of what sort of garbage collector you are running on the underlying machine and on top of that there is also no guarantee that the gc call will free up any memory at all or the JVM will simply ignore the request.
From the docs
Java Docs wrote:
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
It says here that the JVM will have made the best effort . It does not guarantee that the 'effort' may be as what you expected .
Muhammad Saif Asif Mirza
OCJA(5/6) OCJP(6) OCJWCD(6)
But my question still remains unanswered .. "Why Oracle/Sun has added System.gc() method in Java API for Java Developers ?" .
As you have already mentioned in your post that we can not guarantee when GC will be run by JVM when we execute System.gc() command , we do not know whether it will be minor GC or major GC because it depends on type of GC Collector algorithm JVM is using.
So when we have so much uncertainty about System.gc() method usage, its implementation and implications, why we have this method in Java API ?
Personally, I have used System.gc() just after creating a big display in a single user system, when I am sure the user will be taking some time to read and ponder the display and will not be needing cpu time right away. Otherwise, just let system handle it.
I can only think of a few scenarios where it might be useful.
1. As William says above, when you expect the user isn't going to be needing your app to do much with the CPU anyway. Might as well get some housecleaning done in the down time.
2. Just before you start an operation that you want to run smoothly, with no hiccups. Do the GC now so that it's less likely to kick in during that operation. This is really the same thing as #1, except that #1 focuses on "no reason not to do it now" while this one focuses on "I don't want to do it then. They're both about us predicting when a GC will be less intrusive.
3. To try to prevent an OutOfMemoryError. In theory, calling System.gc() shouldn't be able to prevent OOME, since GC is required to run before an OOME is thrown anyway. However, OOME isn't only thrown when we try to allocate memory and fail. It's also thrown when the JVM spends more than 95% of its time doing GC and only reclaims 5% of the total heap. Or something like that. I forget the exact numbers, and they're tweakable with command line options anyway. The point is, however, aside from any launch-time tweaking, we may think that by calling gc() frequently enough, or by calling it when we know a big chunk can be reclaimed, we might prevent it from crossing that dreaded threshold of "too much time GCing for too little payback." Basically we're just hoping that the timing of the GC we introduce this way will prevent us hitting the threshold. This one would be really hard to predict though, and probably only valid in certain very narrow, specialized cases, if at all.
4. Back in the early days of Java, like most parts of the JVM, GC was clunkier than it is now. Calling gc() back then may have been more than just a hint, or may have been a stronger hint than it is now. The JVM may have benefited more from our "help" then than it does now. But like a number of things that aren't currently useful, it's still around because taking it out might break a lot of existing code.
Note that for the first 3 in particular, we're guessing and hoping that it may help somewhat, but we really have no way of predicting if it will have any effect, or how much.
Santosh Kumar Nayak wrote:Well In that context if we are asked that can we make a explicit call to System.gc() ?
You can make as many explicit call to System.gc() as you like, there's just no guarantee they will do anything.
Personally I think the 4th point Jeff made is the most pertinent. Computer performance and garbage collection algorithms have improved massively since Java was first released and consequently gc() is probably now all but redundant.
I do remember many years ago adding multiple gc() calls in an attempt to force a gc before running an animation task but that was in the days when a gc cycle stopped the animation for a noticeable fraction of a second.