I was just too bugged working with Eclipse and waiting too long everytime I went back to a previously minised Eclipse Window. I checked the Windows Task Manager and noticed that even though I have 512MB physical RAM, the VM size was 100MB for Eclipse and the physical memory being used up was only 30MB.

From Croctech

A Cure For Eclipse Sluggishness If you've ever been driven nuts by Eclipse's constant freezes under Windows, then this plugin will fix the problem.

The performance of Eclipse (and other large Java applications) has long suffered due to the Windows virtual memory manager. Windows has a tendency to preemptively swap Java processes out of physical memory, even when there is still plenty of physical memory available. This interacts very poorly with Java processes, which do not have good locality and touch a lot of memory. The problem is exacerbated when Java performs garbage collection, which causes the Java process to touch lots of memory that has been paged out to disk. Ever had Eclipse randomly hang for 15-20 seconds? This is most likely the culprit.

I wrote a simple plugin for Eclipse that uses two functions in the Windows API - SetProcessWorkingSetSize() and VirtualLock() - to encourage Windows to keep more of the Eclipse Java process in physical RAM. This plugin adds a preference page where you can adjust the minimum and maximum working set size (i.e. the amount of memory Windows is supposed to keep in physical memory when the process is in use). However, Windows will happily begin swapping out Eclipse below the working set size if the Eclipse window is minimized. By enabling the VirtualLock checkbox, the plugin will force Windows to allocate physical memory, so even when Eclipse is minimized it won't be swapped out. This is very effective in eliminating that sluggishness in Eclipse after not using it for a while.

(Yes, this is an evil nasty hack. But it's an evil nasty hack that works really well.)

http://suif.stanford.edu/pub/keepresident/