Generally, each dll loaded has a preferable starting address, which is determined by the compiler, by default, assigned by name. During the loading, if conflict occurs, loader will relocate them. So, if too many conflicts happens, it may cause starting performance problem.
In one of our product, we are using a bunch of 3rd binary packages from one company, the names follow the pattern “FO***”, for most of client machines, they seem to be the only libraries to be loaded into address space starting with that name. After watching the run-time address space of our distributed program, it seems that the compiler is not allocating compact enough address policy, there are several mega free spaces between two adjacent libraries. Since our product is memory extensive one, I manually rebased those dlls and it seems that dozens of 10M memory can be grouped into one 150M memory finally. So, some operations which caused out-of-memory exceptions now can work well.
The basic step is rather straightforward.
- Dump the run-time address space for you program first by using vmmap.exe from sysinternal or using !address from windbg, the first is much more friendly.
- reassign the proper base address for dlls
- Use rebase.exe from visual studio 2008 command, the syntax is:
rebase.exe –b newAddress dllName.dll
Just found another interesting method:
rebase.exe /b Ginger.dll GooseBerries.dll
can make those two dlls auto rebased back-to-back.
No comments:
Post a Comment