Eclipse等java應用的性能長期收到windows虛擬內存管理系統的約束，Windows有一個將java進程交換出物理內存的趨勢，儘管還有大量可用的物理內存存在。這個處理使得java進程處於劣勢，接觸不到多少內存。這個問題在java進行垃圾處理的時候會凸顯出來，因爲這時java進程要處理很多已被分頁的存到硬盤的存儲。
這個插件增加了一個可以通過minimum and maximum調整工作時內存（比如當進程運行時所需要的在物理內存中的內存總量）的優先頁。然而，windows仍然會在eclipse最小化時，將其交換出內存。但是但我們選中VirtualLock checkbox時，插件就會強制windows分配物理內存給eclipse，即使他最小化了。
這對編程時需要將eclipse切換掉，再換回來時的遲滯很有效果。
原文：
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.)