Heap allocation/deallocation in Windows... what´s happening?

Performance Tuning
#1

I´m using a good amount of Heap memory to load some resources. After the load, most of the heap used become garbage, wich i believe, JVM is doing GC.
But in WIndows Task Manager it seems that does not free the memory used. The most weird is when i minimize and then opening the window i can see a huge decrease of memory of my game (From 150mb to 30mb).

What´s happening? How i could possible solve this without asking my customer to minimize the window to reduce memory allocation? ???

I tried MinHeapFreeRatio/MaxHeapFreeRatio but doesn´t seem to be a VM issue. Is there any native workaround to force windows free all this memory?

OS: Windows XP Pro SP2
VM: Sun JVM 1.6.0_01-b06

#2

Ok, basically there is no benefit in freeing it from Windows memory immediately. Even Microsoft’s documentation on .NET and its memory management will tell you that. Basically what happens is that whether you remove it from main memory or not, an allocation is not being used then something else will take it’s place. So what the memory managers of .NET and Java do is to register in your program that the memory is removed, but it will reuse that memory - hence not having to reallocate the memory in Windows.

#3

The reduction in allocation when minimized is a Windows feature. When all an application’s windows are minimized Windows decides that you’re not really using the application at the moment and allows all the physical RAM it has allocated for itself to be swapped out to disk. If you look at the Virtual Memory column in task manager you can see that it’s all still allocated; but the amount of physical RAM that it’s got is now just a fraction of that.

Cas :slight_smile:

#4

I just saw the Virtual Memory column and i notice that is not droping the use. I will think a way to reduce the heap usage at load.

Thanks for the answers.

#5

Also note that what I said still applies; .NET and Java does not deallocate memory straight away when garbage collecting. This is so that it can reallocate the same areas of memory - you could call it an allocation optimisation.

#6

Worth reading: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6498735

#7

I think that the VM column shows virtual address space that an application has reserved, not necessarily committed. Committed address space is either mapped to physical memory or paged out.

Bear in mind that a JVM resizing its native heap all too frequently might lead to address space fragmentation - not good for applications that require large contiguous regions say for NIO buffers. Obviously this is a concern for 32-bit platforms only.

#8

[quote=“mabraham,post:7,topic:30247”]
That’s exactly what I’m saying; I know for certain that .NET does not deallocate memory for that reason. Imagine if every time that your application allocates/deallocates memory that Java made a call to VirtualAlloc and VirtualFree! It would make for a very slow application!