[THIN] Re: DLL rebasing
- From: "Nick Smith" <nick@xxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Fri, 18 Nov 2005 16:45:11 -0000
I love it when the memory wizards discuss. Don't understand more than 2
words of it, mind, but it feels a bit like I'm peeking over real
scientists shoulders.
Nick
_____
From: Tim Mangan [mailto:tmangan@xxxxxxxxxxxx]
Sent: 18 November 2005 16:29
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: DLL rebasing
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:
