Will the GC take care of all memory management issues (memory leaks) ?
Is there any case where you don't want the GC to take control of some part of your code ?
It will take care of the classical memory management issues (allocated memory not getting deacllocated when no longer in use), though it is still possible to have memory leaks with a GC system - this will be more subtle and will occur when objects still hold references to other objects, even when they no longer need to.
See the question Why can .NET not have memory leaks? and it's answers on StackOverflow.
There may x. situations when you want full control over memory allocation, but frankly, the benefits of a GC system are such that you will normally not need to.
There are many memory issues (dangling pointers, buffer overruns and similar) and resource issues (memory leaks, other resource leaks). Garbage collector takes care of:
The language not allowing pointer arithmetic takes care of:
Neither can solve other cases of resource problem where you forget to remove reference to the memory/resource from somewhere, so you can still have memory leak with GC (Exception objects are especially notable for referencing many things you are not aware of).
While GC can help you with releasing other resources than memory by use of finalizers (destructors), it will release those resources with non-deterministic delay, which is often not appropriate for resources like files or network sockets. To handle this kind of resource problems you need some language construct for scoped resources like using statement in C#, RAII idiom in C++ or the latest extension to try syntax in Java 7 and it's still only help, because you need to use it in the code.
Not allowing pointer arithmetic and creating addresses from numbers is needed to be able to run precise garbage collector. Some useful optimizations like compacting can only be implemented in precise collectors (you can only move objects if you can tell for sure what is a reference, so you can update it; you can't do that in C/C++).
Garbage collection works well for memory. If you have a ton of memory, why run around cleaning up every byte as it is done with? GC typically responds to "memory pressure" and cleans up when needed. This is a good thing for memory. However, if you have an object that holds a non-memory resource (file handle, database connection, lock) waiting until memory pressure triggers GC will generally meaning holding that resource way too long. You need another approach for those resources. That might mean a reference counting shared resource, with deterministic release when the reference count reaches zero, or the using/Dispose approach of .NET.
GC systems is a software that attempts to optimize the usage of memory for a running program.
GS system is the responsibility of and is a component of the framework (JVM/.NET).
It can free memory for some objects that it predicts as not going to be needed by an application after a given point in the processing.
In .NET it can only free memory for some .NET native objects and not for MS COM object.
MS COM objects used in .NET must be freed explicitly.