I have created an object in Java, Named FOO. FOO contains a large amount of data.. I don't know say for a ten mega byte text file that I have pulled into ram for manipulation.(This is just an example)
This is clearly a huge amount of space and I want to deallocate it from memory. I set FOO to NULL.
Will this free up that space in memory automatically? or Will the memory taken by the loaded text file be around until automatic garbage collection?
There's no guarantee that JVM will do it right away, you can try to force it by using System.gc()
Setting foo = null; does not mean that foo will be garbage collected immediately. Instead, it will be collected when the GC next runs, if it can be. When foo is collected, any objects for which it holds the sole reference will also be eligible for collection and therefore collected.
When you set the reference of any object to null, it becomes available for garbage collection. It still occupies the memory until the garbage collector actually runs. There are no guarantees regarding when GC will run except that it will definitely run and reclaim memory from unreachable objects before an OutOfMemoryException is thrown.
You can call System.gc() to request garbage collection, however, that's what it is - a request. It is upto GC's discretion to run.
Using a WeakReference can help in some cases. See this article by Brian Goetz.
The garbage collector will free the memory after you "destroy" the reference. i.3 Setting the object reference to null. You can use forced garbage collection option but you should use it with care. The Garbage collector is designed to use an optimized schedule so calling the System.gc() may ruin the rhythem and possibly have less performance due to unnecessary task switching.
Alternatively you can think about a way that allows you to not to load large amounts of data into memory. If you can gain that by improving your code that would be much better.
Note that even calling System.gc() does not guarantee that that JVM will do it right away.
System.gc() is just a request and there is no guarantee that it's effect immediately.
Actually the object is not named FOO. FOO is the name of a variable which is not the object; the variable contains a reference to the object. There could be several distinct variables containing references to the same object.
The garbage collector works by automatically detecting unreachable objects: these are objects which the application cannot use anymore because it has irretrievably forgotten where they are (the application may possibly access any object for which it has a reference to, including the references stored in field in objects it can access, and so on).
When you set FOO = null, assuming that FOO contained at that point the last reachable reference to the object, then the memory is released immediately, in the following sense: at the very clock cycle at which null is set in FOO, the object becomes unreachable. Therefore, the garbage collector will notice that unreachable object and reclaim the corresponding memory block; that is, the GC will do that the next time it can be bothered to run. Of course, the actual bits which constitute the object may linger a bit in memory; but that block is nonetheless "free" since the memory allocator will automatically run the GC when free memory is tight. From the application point of view, the object is as good as dead and the corresponding memory is free since that memory will be reused the next time the application needs it. The whole thing is automatic.
Things are a bit more complex with regards to the operating system. If an unreachable object is free memory from the application point of view, it is still, as far as the OS is concerned, a block of RAM dedicated to the running process. That block of RAM may be given back to the OS only when the GC (which is, at the OS level, a part of the process) actually runs, notices that the object is unreachable, and condescends to give the block back to the OS. When the GC runs heavily depends on the GC technology and how the application allocates objects; also, some GC will never give back the block the OS at all (the GC knows that the block it free, the memory allocator will reuse it at will, but not other processes).
System.gc() is a hint to the VM, so that it runs the GC now. Formally, it is only a hint, and the VM is free to ignore it. In practice, it runs the GC, unless the VM was instructed not to obey such commands (with Sun's JVM, this is a matter of a specific command-line flag). Even if the GC runs, it does not necessarily give back the memory to the operating system. System.gc() is not terribly useful.