New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: implement SysUnused on Windows #5584
Labels
Milestone
Comments
Issue #4960 has been merged into this issue. |
MEM_RESET will help because Windows memory manager does not need to write the contents of memory page to the disk. But the problem remains, because the MEM_RESET page still remains part of "committed" memory. "committed" memory is a finite resource. From the top of my head, I cannot tell you how amount of "committed" memory affects Windows memory manager, but I suspect it does. What would need to change in go runtime for us to be able to de-committ memory? I suspect we won't be able to de-committ memory, we should use MEM_RESET then. I am happy to do it. But it is low on my todo list. Alex PS: Why VirtualAllocEx, not VirtualAlloc? PSS: I bleive MEM_RESET is available on every Windows OS. Even on w2k. "MEM_RESET is supported starting from Windows 8" - do you have a reference to that? |
Say you have 4GB of RAM. Write a program that allocates and frees 3GB. Start the program, wait till the 3GB will be marked as unused. Start another instance, wait till the 3GB will be marked as unused. And so on. If you can start 10 such programs w/o killing the machine with swapping, it works as expected. You can use debug.FreeOSMemory to not wait for 5 minutes. |
Owner changed to @dvyukov. Status changed to Started. |
This issue was closed by revision 4e76abb. Status changed to Fixed. |
I'm experiencing a similar issue (FreeOSMemory/garbage collection is not returning memory to the OS consistently) on a 64-bit Windows 7 machine, particularly with the go1.3.3 windows/386 release (but also to varying degrees with other releases). I've attached a simple test program to demonstrate the problem. It waits 5 seconds, allocates ~95MB of memory via a slice, sets it to nil, and periodically calls FreeOSMemory to try to return the memory to the OS. By watching the "Private Working Set" column for the program in the Windows task manager while it is running, you can see the memory usage starts out small (as to be expected), increases to include the 95MB of allocated memory, and then decreases (or doesn't...) after FreeOSMemory is called, depending on the go version used. The amount of memory actually returned to the OS varies with different go releases as well (I tested the most recent releases). Here are my findings, running memtest.go with "go run memtest.go" on various go releases: * go1.3.2 windows/386: The memory is never returned to the OS. * go1.3.2 windows/amd64: This works correctly. The memory is released and the memory usage returns to close to what it was when the program started (memory in-use was ~1.5MB after FreeOSMemory was called). * go1.3.3 windows/386: The memory is never returned to the OS. * go1.3.3 windows/amd64: This works correctly (memory in-use was ~1.5MB after FreeOSMemory was called). * go1.4rc1 windows/386: Some memory is returned, bu not all of it: ~13.5MB was still in use after FreeOSMemory was called. * go1.4rc1 windows/amd64: Some memory is returned, but not all of it: ~7.6MB was still in use after FreeOSMemory was called. These results were all repeatable which each respective release. I kept the program very simple, and didn't bother allocating a larger amount of memory because it is was still able to clearly demonstrate the differences in behavior across the different go builds tested (on my machine at least). I haven't tested yet with other allocation sizes, and I'm not sure if some of this behavior is expected. My results seem to indicate that 1.3.2 windows/amd64 and 1.3.3 windows/amd64 do the best job of returning as much memory as possible back to the OS, as the memory usage returns very nearly to the amount of memory in-use when the test program is first started (prior to allocating the slice). I'm no expert on Windows memory management, but I thought it was interesting that the 386 and amd64 builds behave so differently, and wondered whether running the 386 build on an amd64 machine might be a factor. I haven't be able to test the 386 build on a 32-bit Windows installation as of yet, but I wanted to try that as well for comparison, and still can if that would be helpful. P.S. I'm using the 386 build because my the program I'm writing uses interacts with legacy 32-bit Windows COM libraries, so I can't use the amd64 build in my current situation. Attachments:
|
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by raheelgup:
Attachments:
The text was updated successfully, but these errors were encountered: