asp.net - Under what circumstances will .NET processes and AppDomains share loaded assemblies in memory? -

i'm looking more details around when , how .net applications share loaded assemblies. i'm interested in sharing between os processes, between appdomains within same process. sharing assemblies reduces system memory usage avoiding having multiple copies of same assembly in memory, presume main benefit interested know if there other benefits and/or implications.

a summary of i've learned far...

1. sysinternals process explorer can used list .net process's appdomains , assemblies loaded each appdomain.

2. a .net process appears load 'core' assemblies appdomain called 'shareddomain' (it's reasonable assume shared between appdomains within current process).

3. task manager , process explorer report not insignificant memory usage numbers 'working set shared' , 'working set shareable', it's not clear being shared. (is 'core' assemblies within shared appdomain? other [non-core] assemblies shared too?

4. in simple test launched 2 copies of standalone .net app , attached visual studio debugger each. 'modules' view shows loaded assemblies , addresses in memory. in test case each loaded module located @ same address in 2 processes. (does indicate sharing, or virtual address space not shared?)

5. asp.net 4.5 supports sharing of assemblies via mechanism called assembly interning (see look @ sharing common assemblies in asp.net 4.5, sharing common assemblies, sharing common assemblies aspnet_intern.exe). appears working setting file system symbolic links (symlinks) different web apps point shared bin folder, hence raises question of whether asp.net using symlinks trigger standard assembly sharing behaviour in .net, or whether there more specific asp.net , iis apppools going on.

note. on machine visual studio 2013 installed, aspnet_intern.exe can found in:

c:\program files (x86)\microsoft sdks\windows\v8.1a\bin\netfx 4.5.1 tools\

there have been further improvements asp.net start-up time , memory usage in later versions of .net , windows server; see asp.net app suspend – responsive shared .net web hosting, performance improvements asp.net shared hosting scenarios in .net 4.5, i'm not sure how relevant these changes question.

asp.net assembly sharing covered in book introducing .net 4.5.

also wondering whether jitted code shared or not, since loaded assembly consists of msil, resources, metadata, etc. , further memory must allocated when code jitted.

there discussion assembly sharing in compact framework (we believe in sharing, msdn blogs, abhinaba basu)

---update---

i used sysinternals vmmap tool examine 2 apppools, 1 asp.net assembly internign set up, other without. 'touched' test aspx page cause asp.net load assemblies (and global.asax runs small amount of code, causes jitting).

the reported memory usage figures 2 apppools similar, working set, ws private , ws shareable same. ws shared larger in 'interning' apppool. unexpected (to me) since there no other process share with, vmmap shows memory blocks (marked '.text' , execute/read protection) shown sharing memory in interning apppool, whereas same assembly in other apppool not sharing. interpretation of blocks of virtual memory in process being mapped same physical memory, , reported 'ws shared'.

aslr

regarding assembly space layout randomization. vmmap tool shows many memory blocks type of 'image(aslr)'. aslr randomises location of assemblies in memory thwart malware, , wondered if preventing assembly interning working correctly. disabling aslr machine using emet tool did cause assembly addresses more regular didn't change reported memory numbers, seems not affecting assembly interning. it's worth noting vmmap still showed images 'aslr' against them, suspect means assembly/image marked supporting/allowing aslr, not aslr in effect.

one case in assembly sharing occurs assemblies compiled native code ngen.exe. let me cite "clr via c#" (chapter 1)

the ngen.exe tool interesting in 2 scenarios:

...

reducing application’s working set - if believe assembly loaded multiple processes simultaneously, running ngen.exe on assembly can reduce applications’ working set. reason because ngen.exe tool compiles il native code , saves output in separate file. file can memory-mapped multiple-process address spaces simultaneously, allowing code shared; not every process needs own copy of code.