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.
###@###.### 2004-11-10 17:43:30 GMT