KeepResident Eclipse plugin

 

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.)

 

KeepResident Eclipse plugin地址