[THIN] Re: DLL rebasing
- From: "Tim Mangan" <tmangan@xxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Fri, 18 Nov 2005 11:28:34 -0500
I don't think this will the .net dll to be shared in virtual memory.
Traditional dlls share code pages only when the page is identical to what
the cache manager maps into a copy/write page. Any write to the copy/write
page triggers a copy (which happens when the rebase-on-the-fly occurs). So
the CLR may know what it is doing, but it can't get the cache manager to map
a copy/write page with that code. If it could then so could the loader that
looks at the traditional dll and rebases it. So each use of the .net dll
gets its own copy in virtual memory, no matter what.
tim
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Lilley, Brian
Sent: Friday, November 18, 2005 10:31 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: DLL rebasing
I have looked a little further into the topic of memory sharing with .net
applications and believe that .net apps will scale well in a multi-user
environment, in fact.. probably better than traditional dlls.
This I believe, is because the CLR is 'rebasing' as it goes. Let me explain
what I mean by this. Lets say process A has a DLL called 'File'
instantiated. The .NET CLR will have loaded the 'File' DLL code for that
object class at user memory address space 5000 for example. Now, process B
wants to use an object from the same 'File' DLL.... so, since the MSIL code
is being compile to machine code on the fly, the compiler can simply map any
address space in process B to the 'File' code in the memory space of process
A. So basically, the .net CLR knows up front what the memory space looks
like as it creates the code, traditional DLL's don't..
I am continuing to look at this and probably setup some testing and bore you
further with the details.
cheers, Brianos.com/handsome=on
============================================================================
==
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
============================================================================
==
Other related posts:
