[THIN] Re: DLL rebasing
- From: "Lilley, Brian" <brian.lilley@xxxxxxxx>
- To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
- Date: Tue, 15 Nov 2005 18:45:10 -0000
Yeah, thats pretty what I was trying to say but not quite as clear as this,
thanks Tim.
And, why would a dynamic CLR compilation not share dll code? I'm sure that a
.net dll can be configured to be shared across app domains? Apparently there
is a version of .net dll rebasing.. which obviously isn't memory address
rebasing since there isn't any memory addresses, but some kind of rebasing
taken place if you precompile your code and something whizzy happens in the
runtime bit of the CLR.
'.Net is sh1t loads faster than Java', when we talk about Wintel Terminal
Servers, adn so I don't think Java sets a precedent for .net? thats comparing
apples with Oranges surely?
Brianos
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On Behalf Of
Tim Mangan
Sent: 15 November 2005 15:59
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: DLL rebasing
On the confusion - Bernd was referring to "off-line" rebasing of the dll so
that the "on-the-fly" rebasing by the OS does not occur. It is the
"on-the-fly" rebasing (sometimes called the write/copy issue) that causes
non-sharing. The "off-line" rebasing is essentially what RTO, Appsense,
triCerat, and now PS4 do.
While I have not checked it, I would certainly not expect the dynamic CLR
compilation to share. Maybe I need to look more closely at that.
tim
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
Lilley, Brian
Sent: Tuesday, November 15, 2005 7:09 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: DLL rebasing
I'm not sure I agree with the point about bad scaling with .net because, as I
understand it, .net CLR dynamic (re)compilation model allows for greatly
reduced memory usage in terms of moving running code around in the address
space to ensure matches and sharing of code pages. I don't know if that is how
they implement it, but I would be surprised if that isn't the case. In fact,
the whole virtual model would allow for far better memory sharing opportunities
than the traditional win32 memory model does.
Also, I was confused when you said "Code pages were not written to or changed,
and could be shared if they were located at the proper base address (this is
what dll rebasing does - it ensures that code pages are in sharable locations).
Data pages, being unique to each instance of each application are inherently
unsharable.".... Isn't it the case that standard dll rebasing in fact stops
code sharing because if a process rebases its DLL because of a conflict, then
it can no longer share that dll code with another process... I wonder if you
meant that your RTO software's DLL rebasing and learning and saving rebased
images.
I would say in general that although the abstract level of .net looks like
dumbing down, I believe that .net is considerably more complex and provides
considerably more powerful possibilities. twenty years ago, we scoffed at the
MS programming model, then we scoffed at COM... ok, .net/Java is hugely
bloated.. we accept that and combat that with ever more powerful and faster
computers... I think this is progress... but not entirely sure given that my
windows based motorola mpx220 manages to run for all of a couple of days before
the battery dies.... ???
cheers, Brian
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On Behalf Of
Tim Mangan
Sent: 14 November 2005 20:29
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: DLL rebasing
Bernd is correct, at least for C# /VB dlls. I have seen some write/copy code
pages in .Net dlls that I believe are probably C++, however they are not
rebasable for a different reason, and rebasing them will cause them to fail.
There is a high correlation between these dlls and those which break if you let
MPS4 mess with them.
tim
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
Bernd Harzog
Sent: Monday, November 14, 2005 1:50 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: DLL rebasing
As a part of its continuing efforts to dumb down programming, Microsoft has
done some of the same sorts of things with memory management for .Net
application that the Java folks did for Java applications. In the pre-.Net C++
and VB worlds, code was broken into two types of pages, code pages and data
pages. Code pages were not written to or changed, and could be shared if they
were located at the proper base address (this is what dll rebasing does - it
ensures that code pages are in sharable locations). Data pages, being unique to
each instance of each application are inherently unsharable.
What M$ did with .Net is make all pages data. So, the complexities of managing
memory addressing are dramatically reduced for the developer, at the cost of
making the entire application eat a whole lot more memory. As .Net applications
start to make their way into production in TS environments, it is going to be
really interesting to see how badly they scale in comparison to their
predecessors.
Cheers,
Bernd Harzog
CEO
Applications Performance Management Experts
www.apmexperts.com
bernd.harzog@xxxxxxxxxxxxxx
770-475-4249
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On Behalf Of
Lilley, Brian
Sent: Monday, November 14, 2005 6:13 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] DLL rebasing
hi list.. please tell me I'm not just making this up... but... am I right in
thinking that DLL rebasing would not be relevant with .net applications. or,
at least .net dll's being loaded post mscoree engine start up, since the .net
dll's are being loaded in a virtual environment.
cheers, Brianos
==============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==============================================================================
==============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==============================================================================
==============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==============================================================================
Other related posts:
