views:

1040

answers:

2

According to this article rebasing is not necessary for .NET assemblies due to JIT compilation of the code. The article states:

"JIT-compiled code does not have a rebasing problem since the addresses are generated at run time based on where the code is placed in memory. Also, MSIL is rarely affected by base address misses since MSIL references are token-based, rather than address-based. Thus when the JIT compiler is used, the system is resilient to base address collisions."

However, I have noticed that VS2008 assigns the default 0x0400000 base address to all assemblies (project properties > build > advanced) and if I do a listdlls /r for my process all my .NET assemblies are in fact rebased per default.

If I assign addresses myself, no rebasing is done.

My question is: What is rebased in this case and why?

EDIT: I should add that I am not talking about NGen'ed assemblies.

A: 

What OS are you running? I know that the vista and beyond introduced ASLR which randomizes the address space it loads dlls into. This happens for system dlls but not sure about .net - maybe something to look into.

keithwarren7
+2  A: 

CLR Loading mechanism uses LoadLibrary behind the scenes, so this is what you observe: 2 assemblies can't be loaded at the same address. Now what people often mean when they try to rebase a dll is to avoid the perf. hit of fix-ups, e.g. absolute addresses & function calls need to be "relocated" with the loaded base-address. CLR does not have this problem (not sure about static data in the application, which is the second part of those fix-ups, I would need to read up on this), because MSIL code is loaded on-demand when you call a function in the managed code. The MSIL then gets jitted and placed on the heap, a different one from normal object heap I believe, in the same manner CLR allocates and lays out new objects in your application.

liggett78
I understand that there's no reason for the fix-ups, but since we are loading assemblies from a network drive, rebasing may become an issue due to the copy to pagefile part of the rebasing. Any links with details would be appreciated. Thanks.
Brian Rasmussen
AFAIK, copy-to-pagefile is the direct result of those fixups,because pages with executable code become writable/private to the process, so the OS can no longer reload them directly from the dll. Do you mean this?
liggett78
There is an old (seems like from middle-age) but still valuable article at http://msdn.microsoft.com/en-us/library/ms810432.aspx from 13 years ago about rebasing (native code).
liggett78