System.gc() query

[Abhay Agarwal]

Since we know that System.gc() method do not gurantees that it will force JVM to perform GC then why this method System.gc() is being added in Java API ?

Another query is - if JVM tries to perform GC based on System.gc() call, whether that GC will be Full GC or Minor GC ?

~abhay

[Saif Asif]

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 .

[Abhay Agarwal]

Hi Saif

Thanks for quick reply.
I agree with your point.

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 ?

Thanks
Abhay Agarwal

[fred rosenberger]

Questions along the lines of "Whey did the original designers do X" can only be answered by the original designers. To the best of my knowledge, none of them hang out here.

[William Brogden]

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.

Bill

[Jeff Verdegan]

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.

[Abhay Agarwal]

thanks for all the replies.
I have got my answer.



~ abhay

[Santosh Kumar Nayak]

Well In that context if we are asked that can we make a explicit call to System.gc() ?

What should be the answer as we can only place a request for the same.

Should it be no or yes ?

[Tony Docherty]

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.

[Luan Cestari]

I had some very heavy load unit/integration tests that I put called gc(). That helped to not set unnecessary very large Xmx and due the tests are too fast to the GC act without a hint.