java - garbage collection

Question

Why the method call System.gc() doesn't guarantee that the Garbage Collector algorithm will run at that moment? Why it cannot certainly reclaim all unused object's memory whenever it is invoked ?

Answer 1

1. Forcing object destruction is sign of bad coding so Java might wanted to avoid developers from getting addicted to it.
2. If Java gives you freedom of forcing of object destruction, improper use of it might have adverse affect of application performance.
3. This restriction allows you (force you) to put more focus into business logic than memory managemnt
4. JVM is the best person to decide when memory management is required and how to do it.
5. You can (should) trust JVM and let it handle things in better way than we can.
6. Still do you really want to force object destruction? If yes, WHY?

Answer 2

In order to ensure that programs run smoothly within the JVM, the JVM itself manages garbage collection. Garbage collection has become quite sophisticated. When you ask the system for a GC run, which algorithm are you expecting? A "full GC"? There are multiple heaps, as well; which one is the garbage you are concerned about on? You don't know and this method doesn't indicate.

Suppose calling System.gc() always triggered a full GC. An errant program could easily grind JVM performance to a halt. Defensively, the JVM would want to limit the frequency at which it responded to such calls.

If you are running in a JVM on a non-embedded system (e.g. a server or a desktop computer), there should be no reason for you to concern yourself with any aspect of memory management other than to monitor it and code efficiently.

Answer 3

There are several metrics that are utilized to evaluate garbage collector performance , some of them are:

• Throughput—the percentage of total time not spent in garbage collection, considered over long periods of time.
• Garbage collection overhead—the inverse of throughput, that is, the percentage of total time spent in garbage collection.
• Pause time—the length of time during which application execution is stopped while garbage collection is occurring.
• Frequency of collection—how often collection occurs, relative to application execution.
• Footprint—a measure of size, such as heap size.
• Promptness—the time between when an object becomes garbage and when the memory becomes available.

Now If JVM listens to System.gc() like good pet and guarantees to perform action on each System.gc() call, Imagine what would be the performance of application if it is called many times within program.!!??

1. Throughput will decrease
2. Garbage Collection overhead will increase.
3. Application will pause many times as it is busy in recollecting the memory.
4. If Footprint is large , The garbage Collector would have to scan all memory area for recovering the memory , no matter if there are objects eligible for garbage collection or not.

So , after looking through these points I guess it provides the sufficient reason to JVM to not respond to System.gc on the application choice , but on its own algorithm. And Garbage Collection reclaims all unused object's memory for sure , but its invocation is entirely dependent on JVM own Algorithm rather than on the user's choice.

Source: Memory Management in the Java HotSpot™ Virtual Machine - Sun Microsystems

Answer 4

it cannot certainly reclaim all unused object's memory whenever it is invoked

This assumption of yours is false. In most cases the Garbage Collector could reclaim all unused objects at any point in time. However, if the standard Java library provided a method that would guarantee that, it would put a completely unreasonable burden on the GC subsystem to provide a service that is most of the time useless and could be even damaging.