Simply download the plugin and extract it to your
There will be a new preference sheet in Window->Preferences called "KeepResident Preferences",
from where you can adjust the plugin.
Unfortunately, to use the SetProcessWorkingSetSize() API, you need to have the PROCESS_SET_QUOTA access right, which is normally only available to users in the Administrator and Power User groups. In Windows XP, you can change this in the "Local Security Settings" if you have Administrator access, or you can just run Eclipse under an Administrator account.
There is a bug in JDK 1.5.0 beta 1, involving loading JNI libraries, that was fixed in beta 2. Upgrade to at least JDK 1.5.0 beta 2 and the problems should disappear. (You can also try rebuilding the JNI library using Microsoft Visual C++, which seems to generate a .dll file that doesn't trigger the bug.)
The working set size tells Windows how much memory the application will typically be using at any given time. Unfortunately, the default value is much too small for big Java applications like Eclipse. Increasing the minimum size will "encourage" Windows to keep the minimum in physical memory, unless Windows determines that the application is not in use.
Minimizing the Eclipse window (or to a lesser extent moving the mouse pointer outside of the Eclipse window) will cause Windows to think that you are no longer using Eclipse, and Windows will begin swapping it out regardless of the working set size. Using VirtualLock() will prevent this and force Windows to keep Eclipse in memory.
You can read what Microsoft has to say about working set size here.
On most systems, I would recommend a minimum size of around 100MB. This will encourage Windows to keep 100MB of Eclipse in memory. The maximum size is not as important, but at least 250MB is a good value. This will allow Eclipse to use up to 250MB of physical memory if it is available and not required by other applications.
Don't go overboard with the size. If you start allocating too much physical memory, Windows will start becoming unstable because it can't allocate the memory it needs.
Using VirtualLock() will *force* Windows to keep Eclipse in memory. Windows has this nasty habit of swapping out 99% of the process memory when an application is minimized or the mouse cursor leaves the window. All of those page faults that occur when you go back to Eclipse cause it to be really slow and laggy. Using VirtualLock() will solve this problem completely.
However, using VirtualLock() is not very nice from a whole-system point of view. Eclipse will still be eating memory even when you aren't using it. And some people have Eclipse stability problems when using VirtualLock().
VirtualLock() will only lock up to your maximum working space size. So you can adjust how much is locked by reducing the maximum slider.
Because the values are just metrics for Windows to use, the precision doesn't make much
of a difference. Still, you can use the arrow keys for fine-grained control,
expand the window to increase the resolution of the slider, or if you are really obsessed,
edit the preferences file in
to specify the exact value you want, down to the last byte.
I do my Java development on Windows so that's what I wrote the plugin for. I'm sure many other operating systems have similar functions to adjust virtual memory usage, so grab the source code and write your own!