StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
479191
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2009-01-26T09:08:39.093
FavoriteCount
0
LastActivityDate
2009-01-26T09:20:11.800
LastEditDate
2009-01-26T09:20:11.800
LastEditorUserId
2695
OwnerUserId
2695
ParentId
479146
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
Jorge
text
Body
I think you're getting confused about shared assemblies and dlls and the process memory space. Both .NET and standard Win32 DLL share code among the different process using them. In the case of .NET this is only true for DLLs with the same version signature so that two different versions of the same dll can be loaded in memory at the same time. The thing is it looks like you're expecting the memory allocated by the library calls to be shared as well, well that never (almost) happens. When a function inside your library allocates memory, and I guess that happens a lot for an ORM DLL, that memory is allocated inside the memory space of the calling process, each process having unique instances of the data. So yes, in fact the DLL code is being loaded once and shared among the callers but the code instructions (and therefore the allocations) take place separately into the calling process space. Edit: Ok, Let's see how JIT works with .NET assemblies. When we talk about JITing the code the process is relatively simple. Internally there's a structure called the Virtual Method Table which basically contains the virtual address that will be invoked during a call. In .NET, JIT works by basically editing that table so that every single call redirects to the JIT compiler. That way, any time we call a method the JIT steps in and compiles the code to the actual machine instructions (hence the Just In Time), once that has been done, the JIT goes back to the VMT and substitutes the old entry that invoked him to point the generated low level code. That way, all subsequent calls will be redirected to the compiled code (so we just compile once). So the JIT is not invoked every time and all subsequent calls will redirect to the same compiled code. For DLLs the process is likely to be the same (although I can't completely assure you it is).
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODLLs, memory mapping, base address, memory usage, and .NET?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USJorge Córdoba
UserOwnerUserId
1. USJorge Córdoba
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. COBut are they sharing code? I assume they will be sharing the IL instructions as these will be loaded in as part of the DLL binary image, but that code has to be JITted before executed, is this shared in any way? Forgive me if you answers this, then I'm not understanding your answer.
 singulars
 PostPostId
 PO
 UserUserId
 USLasse Vågsæther Karlsen

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.