Linked by Thom Holwerda on Thu 19th Mar 2009 06:44 UTC, submitted by Moulinneuf
Thread beginning with comment 353929
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
However, the app domains are implemented as multiple copies of the .NET VM running inside a single process. Even if you have a single process with 10 application domains, you still have multiple VMs, which are deliberately kept isolated from one another. Big deal - pretty much any VM runtime can do that
You learn something new every day
I was under the impression that while appdomains were heavy, it was less overhead then to run multiple java apps. Guess there isn't all that much of a difference other then the shared memory bit.




Member since:
2007-09-08
Except when it isn't.
Application domains can be used to host multiple applications inside a single OS process. However, the app domains are implemented as multiple copies of the .NET VM running inside a single process. Even if you have a single process with 10 application domains, you still have multiple VMs, which are deliberately kept isolated from one another. Big deal - pretty much any VM runtime can do that.
That's how the .NET VM is hosted inside SQL Server, how it's used in IIS for ASP.NET websites, and how it's hosted as a COM object inside other applications.
However, that's not how most .NET applications run. If you run a .NET application, a new process will be created, creating a new instance of the .NET VM along with it.
What it can do is pre-compile the assemblies in the GAC to native code. That way, the native code can be shared by any application using it - the runtime just mmaps the code to memory, and the OS just maps the same block of memory into each VM's address space.
That's something that other VMs don't do yet, although I believe Sun were working on some sort of JIT cache for Java that'd perform the same role.