That first sawtooth graph of the JVM with it rising and dropping is normal. The only time you see it GCing earlier is as the heap goes through false cielings as it climbs to the max memory.
For example, if your have a max heap of 512, but don't specify a minimum heap, then the JVM will start with smaller heaps and resize them as necessary up to the maximum size. If you start with the maximum size, then there's no need to resize and the you end up with that standard sawtooth pattern.
That's, at a glance, a healthy GC running.
It looks to me that the timers are associated with traffic and connections, someone else will better be able to tell you about that. But, again at a glance, those don't look to be your problem.
App servers just do a lot of busy things.
Because of the stability of the system, I think you need to focus on what's different about the operations that would have provoked a heap problem. Was some new content added to the site? Downloading a lot of data perhaps? Something, apparently, abnormal triggered this event.
There was a bug in the past (since fixed, and I assume it's fixed in your version) where large static resources leaked in to the heap (like large PDF files or JPEGs). I don't know if you're doing anything like that or not.
But otherwise, looking at the GC graph, there's no leak there.
At this point I would take a heap snapshot of a "healthy" heap, and if and when you OOM again, snapshot that heap before you restart so you can see what pops out between the two.
As always, the problem with things like heap leaks, especially rogue ones in a stable (and large) piece of software like GF, you can typically only find them when you can duplicate them.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=315300