I'm interested in using tcmalloc on Windows x64, does this work?

I'm just getting started, and when I build I get compiler errors in
atomicops-internals-x86.h presumably because its got x86 assembly code
in it (not x64).

Is there a #define I can set to tell it to I'm on x64?

thanks!

Also, does it work in 64bit on linux?

- Alex

Sorry, windows x64 isn't supported yet.

I don't know what it would take to get it supported.  Maybe not much.
But I don't really know windows, and don't have a 64-bit machine to
play around with.  We do have 64-bit asm instructions for linux, but I
don't know how easy it is to port them to windows-land (if indeed
that's needed).

If you do figure out how to get this to work, we're happy to take
patches! :-)

craig

Thanks for the response Craig.  I don't see myself writing 64bit asm
any time soon, but you never know :)

On Jun 28, 1:39 am, Craig Silverstein <csilv...@google.com> wrote:

I've encountered an access violation while running with ltmalloc in a
32 bit application running on 64-bit Windows 2003 server.  There's an
AV while trying to call VirtualProtect when patching LoadLibraryExW.
Is it safe to not patch this function in Wow64?

BTW: to determine if a 32 bit app is running in Wow64 call
GetProcAddress on IsWow64Process in kernel32.dll.  If it is not
available then the answer is false.  If it is then call it and use the
result.  Some later versions of 32 bit windows do have this function
and return false so it is necessary to call (and it will also return
false if the application and os are 64 bit).

Also, HeapReAlloc is not patched.  Is this fine?

I've tried to run a 32 bit app compiled with the ltmalloc on 64 bit
Windows 2003 server and crashed in the
PreamblePatcher::RawPatchWithStubAndProtections with an access
violation while patching LoadLibraryExW.  I do see it in the
kernel32.dll listed in depends on that platform and based on the
offset listed in depends and the base address the module is loaded at
in the process itself while running (kernel32.dll:
0x7d4c0000-0x7d5f000, LoadLibraryExW offset: 0x10b09, GetProcAddress
returned 0x7d4d0b09).

There is a two step process for determining if you are running in
Wow64 mode.  Call GetProcAddress for IsWow64Process.  If you don't get
a function pointer back then it isn't.  Then call the function.  If it
returns true then it is, otherwise it is not (some 32 bit versions of
windows later on do provide this function apparently so just getting
the pointer back from the GetProcAddress is insufficient).

Apologies for the multiple posts--I thought I lost my initial post mid-
write and rewrote it.

I think I managed to work around this.  So far everything appears to
be loading fine.

I added a boolean flag to WindowsInfo::FunctionInfo to mark whether
the function is Wow64 safe to patch.  I set all to true but
LoadLibraryExW which I set to false.

Then in WindowsInfo::Patch I lookup and if available call the
IsWow64Process function and if the current process is Wow64 and the
target function is not wow64 safe to patch then I continue the loop
skipping the patch.  I store the IsWow64 state in WindowsInfo so I can
use it in Unpatch as well.

K, final post for the night.

From reading the code I don't want to disable that functionality.  It
looks like the VirtualProtect was changing the flags at an inopportune
time of the LoadLibaryExW.  Changing the target flags to rwx instead
of just rw fixes it without losing the functionality.

Hi brent, thanks for your feedback.  Can you go to
   http://code.google.com/p/google-perftools/issues/list
and file a bug report with the problem you found, and, ideally, attach
a patch to fix it?  I want to make sure I do the right thing based on
all the research you've done.

craig

Done, I've entered issues and what I've done to fix them and in most
cases included the code change.  Apologies for formatting re tabs/
spaces in the source files.  Also note the changes are win32 centric
and in some cases (spinlock) require some portability work.