Some questions about the Windows version of TCMalloc

[Giorgio Gambino]

Hello,

I’m studying the Windows porting code of your tcmalloc memory allocator and I have some questions about it:

1. After having done some tests, read some source code comments and consulted on Github the open issues, I gathered that the

patching runtime system is not so reliable (especially if used with VS2015). In the README_windows.txt file I found this:

An alternative to all the above is to statically link your application

with libc, and then replace its malloc with tcmalloc.  This allows you

to just build and link your program normally; the tcmalloc support

comes in a post-processing step.  This is more reliable than the above

technique (which depends on run-time patching, which is inherently

fragile), though more work to set up.  For details, see this link

Unfortunately the linked page is not reachable. Could you please explain  me which are the ways to link tcmalloc to my application?

      Are those all equivalent? And which one is the most safe?

2. Supposing that I want to create another Visual Studio Project with only DLL building related files. What is the minimal set of .h and .cc files that I have to include in it?

3. I saw that pagesize is calculated as the max between dwPageSize and dwAllocationGranularity. Is it necessary to calculate the value in the way here upside explicated?

And are there any situations in which dwPageSize could be greater than dwAllocationGranularity? In my experience with Windows system internals there is no relationship, other than the granularity

          must always be an integre multiple of the page size and can never be smaller. Granularity is a simple counter-measure against address space fragmentation. It has been 64KB forever. Moreover, after

some tests on Ubuntu 64bit machine I’ve noticed that pagesize is always 4KB. So, in the Windows version, if all I said above is correct, the page size will always be 64KB causing more memory

          allocated because of the alignemt boundary.

Thanks for your attention and for the opportunity to study your great

work, which helps me to become a better developer.

[Aliaksey Kandratsenka]

Hi. So I've merged a patch today that seemingly makes patching work
with visual studio 2015. As for overriding instructions, I was able to
find them in my mailbox and pasted it here:
http://paste.debian.net/839102/

> --
> You received this message because you are subscribed to the Google Groups
> "gperftools" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gperftools+...@googlegroups.com.
> To post to this group, send email to gperf...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gperftools/838a7c82-35b4-4f81-84b9-778c6728d93e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Aliaksey Kandratsenka]

Hi. I was also able to test overriding yesterday.

Looks like chromium folks actually rebuild VS C runtime without
malloc, but as Vladimir noted in his email, when linking to static C
runtime, overriding malloc is possible without rebuilding C runtime.
You just have to be careful to provide all symbols.

I had to change the code a bit to work with VS2015. See here:
https://github.com/alk/gperftools/commit/bae98ee62fbc380c9d793680b3ad4704eda96d57
(most of diff is related to switch to VS2015 project)

Malloc debug symbols don't work, but overriding malloc in release C
runtime seemingly works.