Swapping and garbage collection

Performance Tuning
#1

Is there a tuning parameter that allows me to get the JRE to lock its heap in physical memory rather than allowing Windows to swap them out?

I’m just totally sick of minimizing Eclipse to do something and Windows swapping out all bloody 128mb of heap immediately, so when I come back to it it has to painfully, painfully load all of it back from disk in 64k blocks :confused: This takes a long time on a laptop. And the worst bit is it’s probably doing a lot of this swapping on garbage that’s just going to be collected anyway.

It seems to be that garbage collection is not ideally suited to Windows virtual memory management. It could do with this feature if it doesn’t already have it.

Cas :slight_smile:

#2

[quote]I’m just totally sick of minimizing Eclipse to do something and Windows swapping out all bloody 128mb of heap immediately, so when I come back to it it has to painfully, painfully load all of it back from disk in 64k blocks :confused: This takes a long time on a laptop.
[/quote]
Really? My NetBeans is always back in less than 5 minutes. No problem. ;D

#3

There’s only so many cups of tea I can drink in a day…

Cas :slight_smile:

#4

Gah. Think yourself lucky. Linux swaps everything whether you minimize it or not, just because you didn’t press a key for too many seconds. Go for a 20 minute break, and when you get back there is NOTHING in memory, it’s all on disk. Queue a 20 minute wait just for it to all come back again. (best known solution so far: don’t have a swap partition in linux; they’re pretty useless things on modern PC’s anyway, the main exception I can think of being Unreal Tournament, which would crash without the presence of a min 200 Mb swapfile for some bizarre reason (ie not running out of memory))

#5

[quote]I’m just totally sick of minimizing Eclipse to do something and Windows swapping out all bloody 128mb of heap immediately, so when I come back to it it has to painfully, painfully load all of it back from disk in 64k blocks :confused: This takes a long time on a laptop.
[/quote]
Well 64k reads are usually the fastest way to read the disk on Windows. I’ve never really figured out why swapping was so damn slow… I mean you have a harddisk that can go at lets say at least 20MB/s - 6 seconds can swap in your entire 128MB heap. Sure it is a very noticeable delay… but sadly in reality the delays are much longer - thus leading to not just a noticable delay but to, well as you put it, “pain”.

Seems virtual memory doesn’t work very well for any popular OS.

#6

It isn’t the time taken to read the disk so much as that you have to convince the OS that your working set needs increasing. If everything has been swapped out, your working set has been reduced to near zero. When you start working again it will read in new pages, but also remove other pages from your working set. If you are unlucky these will get overridden and then shortly afterward have to be read back in again. The end result is that by the time the OS has finally agreed to grant your app a 100MB+ working set, you will have read that data back in not just once but several times. How many times depends on how much free memory your system has.

#7

/me can hear the awful grinding noises from here

#8

I’m guessing java has no control of memory being swapped or not :frowning:
Maybe if there would be a System.gc() at the event of minimizing the window or something would help a bit…

#9

I think I’d like a tuning option to get the VM to keep its working set at a minimum the size of the current working set, which would appear to solve the problem I have entirely.

Cas :slight_smile:

#10

There is a windows method (SetProcessWorkingSetSize[Ex]) which can specify a minimum working set. Needs special privileges to use it, and if you over do it everything else slows down.

#11

I feel a little JNI coming on…

Cas :slight_smile:

#12

The reason this happens is that Windows trims the working set for processes that are minimized… Described here:

http://support.microsoft.com/default.aspx?scid=kb;en-us;293215