 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / November 2003Understanding the memory handling of value types
Hello, I understand that a value type is stored on a thread's stack as opposed to reference types which are stored in the managed heap. This fact raises some questions for me: a) When I use the console tool "cordbg", and I disassemble some release-code (not debug code, which I learned is quite different), I notice that primitve types can be stored in processor registers rather than on the stack.So, is it correct to say that value types are usualy stored on the stack with exception of the primitive types which the IML-compiler tries to optimize by having them in processor registers? b) If I start seperate .NET application on a system, do they share the managed heap, or is there one managed heap per application instance? Does anybody know articels that would give more insight into that topic? Thanks, Klaus Klaus Löffelmann <fornewsgroups@loeffelmann.de> wrote: > I understand that a value type is stored on a thread's stack as opposed to > reference types which are stored in the managed heap. Not necessarily. See http://www.pobox.com/~skeet/csharp/memory.html > a) When I use the console tool "cordbg", and I disassemble some release-code > (not debug code, which I learned is quite different), I notice that primitve > types can be stored in processor registers rather than on the stack.So, is > it correct to say that value types are usualy stored on the stack with > exception of the primitive types which the IML-compiler tries to optimize by > having them in processor registers? They only need to be *logically* on the stack. As far as IL is concerned, there are no registers (I believe) - the CLR can do what it likes, so long as it makes everything look like it's happening on a virtual machine which obeys the CLR rules, I believe. > b) If I start seperate .NET application on a system, do they share the > managed heap, or is there one managed heap per application instance? One per application at the moment, but I believe one of the reasons for the whole AppDomain business is so that a single host could be responsible for many apps at a time. Whether that host *has* to only have a single heap or not, I'm not sure.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Klaus, Bare in mind that values types can be stored within heap objects, and so the values can exist on the heap in this way too. Whether they ever exist on a stack, I'm not sure of, but I know I have read books before that say they are on the stack, and they can be placed on the heap if they exist within a reference type's blob. "Boxing is not the only way of putting a value type on the GC heap. The other way to achieve it is to make the value type a member of a gc class" Essential Guide to Managed Extensions for C++ by Siva Challa and Artur Laksberb, apress, page 64. Ben Klaus L?ffelmann <fornewsgroups@loeffelmann.de> wrote: > I understand that a value type is stored on a thread's stack as opposed to > reference types which are stored in the managed heap. Not necessarily. See http://www.pobox.com/~skeet/csharp/memory.html > a) When I use the console tool "cordbg", and I disassemble some release-code > (not debug code, which I learned is quite different), I notice that primitve > types can be stored in processor registers rather than on the stack.So, is > it correct to say that value types are usualy stored on the stack with > exception of the primitive types which the IML-compiler tries to optimize by > having them in processor registers? They only need to be *logically* on the stack. As far as IL is concerned, there are no registers (I believe) - the CLR can do what it likes, so long as it makes everything look like it's happening on a virtual machine which obeys the CLR rules, I believe. > b) If I start seperate .NET application on a system, do they share the > managed heap, or is there one managed heap per application instance? One per application at the moment, but I believe one of the reasons for the whole AppDomain business is so that a single host could be responsible for many apps at a time. Whether that host *has* to only have a single heap or not, I'm not sure. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.