What I believe you see here is the concurrent Garbage Collector is doing young generation cleanups, but the heap is constantly churning so it can't get a hold of all the references for an old generation collection. When you hit the perform GC button you're doing a "stop-the-world" collection which blocks all the threads, freezing the heap, and allowing a much larger collection to occur. My main concerns here would be - does a large collection ever occur (after x hours)? Are you seeing OutOfMemory errors with a smaller heap?
1) Do you have the auto refresh button turned on? It may also be that profiler does a small GC (Eden space) before taking a snapshot.
2) This is perfectly normal. Garbage collection takes time and resources (processor cycles). If you've set your heap to a large size, it will wait until it reaches some percentage of that until triggering a garbage collection itself. I think the default free space to live object ratio is between 40% and 70% I know tomcat specifically changed the way it does garbage collection around version 5, tomcat v4 had performance issues because it spent a lot of time running the garbage collector. You may want to do some research here and see if tomcat has custom garbage collection options.
3) No. A nearly full heap is exactly what you're striving for. It may make sense to make the heap smaller so that a full garbage collection doesn't take such a long time. It's trade-off between lots of garbage collections (pauses) and lengthy garbage collections (long pauses). Each app is different, so I generally start with the defaults and tweak as needed. There are lots of options for garbage collection (and alternate collectors) if you're interested.
Java 6 FAQ, Whitepaper