A DESCRIPTION OF THE REQUEST :
One could workaround bug #4412569 under Win32 by invoking a combination of GetProcessWorkingSetSize() and SetProcessWorkingSetSize().

Here is the proposed behavior:

1) Assume Java starts out with a 50MB heap, GC takes place and it reduces its heap to 5MB. Let JAVA_HEAP_SIZE represent the size of the Java heap after GC; in this case, its value is 5MB.

2) Java calls GetProcessWorkingSetSize(GetCurrentProcess, minHeap, maxHeap).

3) If minHeap > JAVA_HEAP_SIZE, set minHeap=JAVA_HEAP_SIZE
4) If maxHeap > JAVA_HEAP_SIZE, set maxHeap=JAVA_HEAP_SIZE

5) Java calls SetProcessWorkingSetSize(GetCurrentProcess, minHeap, maxHeap)

This force the Windows "working set" value to synchronize with the Java "heap size" value and everyone should be happy.

JUSTIFICATION :
The current perception is that Java uses a lot of memory because the "working set" tends to be very large. As bug #4412569 illustrates, there is a very simple way to safely reduce the "working set" value and we should do this automatically on every garbage-collection. Otherwise our process-space will needlessly reserve memory it does not need and end-users will get the undesirable impression that Java is a memory hog.

This is a simple fix so please consider it for upcoming JDK 5.0 update releases.


CUSTOMER SUBMITTED WORKAROUND :
Minimize/restore Java window. Trying to explain to users that this is a Windows bug, not a Java one is a hard sell. If we can do something about it, we should.
  xxxxx@xxxxx   2004-11-10 17:43:30 GMT

N/A

I don't think it is so simple as reducing working set on every garbage collection - there might be performance impact because of that.  Anyway, this is an area of GC team's decisions.
  xxxxx@xxxxx   2004-11-11 10:43:34 GMT

I think that this is an almost solution.  In reality, this is exactly what would happen if you were using malloc()/free() instead of a GC.  So, it would seem to me that  a simple command line property should be available.  That property would hold the percent of the gap space that should be held on a GC.  Everything else should be shed.  Thus, if I know that my application is expanding and contracting too much, I can up that number until it settles down.  If it is set to 100, then GC would not shed VM pages from the working set.

There also could be some automation of management of this value by watching the amount of space allocated since last gc, and taking this into account so that to be allocated/reallocated space in the VM space would be continuously paged which will slow things down tremendously.

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

I have implemented the feature suggested in the request description at app code level. Any application running on a Windows platform (other than 9x/CE) can use it to control the working set size of its own JVM process depending on the size of currently used object memory.
If someone is interested in the source code, please email at mirochmm"the at sign"mail.ru.