Can not release tcmalloc's virtual memory(win7 64-bit)

[GoogleCodeExporter]

What steps will reproduce the problem?
1.my application is mfc dialog project(32-bit)in win7
2.malloc some memory and release it in a function 
3.get the status and  print out.Then call 
MallocExtension::instance()->ReleaseFreeMemory() and 
MallocExtension::instance()->ReleaseToSystem(LONG_MAX) to release memory, then 
get the satus and print out agian.

What is the expected output? What do you see instead?
The expected output should be that the memory in page heap freelist is going to 
be zero.

But what I see is the result in attach "output.txt".

What version of the product are you using? On what operating system?
The newest version download in 15 Dec 2012 from the trunk(read-only).
Win7 64-bit OS, my application is 32-bit mfc application.

Please provide any additional information below.

Original issue reported on code.google.com by sunbaigu...@gmail.com on 20 Dec 2012 at 2:27

Attachments:

• output.txt

[GoogleCodeExporter]

My IDE is vs2005

Original comment by sunbaigu...@gmail.com on 20 Dec 2012 at 2:31

[GoogleCodeExporter]

The windows side of gperftools needs a lot of love. I find it very difficult to 
find people with windows experience to offer any help. In other words, lots of 
issue submissions but very few actual patch submissions. In case you are 
waiting for a quick turn around on this I should advise you that this will not 
likely be the case unless you are willing to spend some time on it yourself.

-Dave

Original comment by chapp...@gmail.com on 23 Dec 2012 at 2:55

[GoogleCodeExporter]

"I find it very difficult to find people with windows experience to offer any 
help"

I would gladly help. In fact I already wrote code addressing this and I would 
highly appreciate if this will be used by many.

I find gperftools as being extremely effective and this part with Windows is a 
weakness that can and should be addressed.

Radu

Original comment by ialo...@yalos-solutions.com on 22 Jan 2013 at 9:30

[GoogleCodeExporter]

I've patch that almost works. Here: 
https://github.com/alk/gperftools/commit/e85ca01c08575e2af42fd4c98b0db27d9a091ba
b

It's as simple as using MEM_RESET flag of VirtualAlloc.

Unfortunately I've just found that it doesn't always work (tcmalloc_unittest 
catches that).

Consider two large malloc requests followed by free()-s of both. Every malloc 
will grab memory from OS by TCMalloc_SystemAlloc which calls VirtualAlloc on 
windows. And windows seems to allocate those regions one after the other. Which 
is normally good. Then when free()-s are called tcmalloc will coalesce those 
free regions, so that even larger malloc does not have to ask memory from the 
os but is able to reuse large free region.

Unfortunately by coalescing those regions tcmalloc completely forgets that they 
were allocated by distinct calls to VirtualAlloc and sadly MEM_RESET refuses to 
work if VirtualAlloc call covers more then one area.

So we're back to drawing board a bit.

Perhaps we can consider allocating virtual memory in much bigger chunks from 
the OS and then preventing tcmalloc from thinking those areas are adjacent.

Original comment by alkondratenko on 10 Mar 2013 at 3:48

[GoogleCodeExporter]

Original comment by chapp...@gmail.com on 11 Mar 2013 at 12:58

• Changed state: Started

[GoogleCodeExporter]

I think I know good way to fix that. Expect working patch soon.

Original comment by alkondratenko on 11 Mar 2013 at 4:36

[GoogleCodeExporter]

Issue 492 has been merged into this issue.

Original comment by alkondratenko on 14 Jul 2013 at 3:06

[GoogleCodeExporter]

Status update: I do have something that appears to work 
(https://github.com/alk/gperftools/tree/wip-windows-unmap).

However I found that chromium fork of tcmalloc actually has a better fix. And 
that's something I plan to integrate after 2.1 release.

Original comment by alkondratenko on 14 Jul 2013 at 3:07

[GoogleCodeExporter]

Porting chromium work instead. Not yet working commits are here: 
https://github.com/alk/gperftools/tree/wip-chromium-decommit

Original comment by alkondratenko on 10 Nov 2013 at 2:20

[GoogleCodeExporter]

Merged a fix.

Original comment by alkondratenko on 1 Mar 2014 at 7:30

• Changed state: Fixed