CLR
-
Hi, I read some paper about how clr works on managed modules, managed heap and jit the managed assembly. That works on heap (reference type). It seems me that only the reference to those oblects are on the stack but the real objects are on the heap. Value type instead are allocate on the stack. I'm wondering what changes if also objects were allocate on the stack; what'll happen? If also objects will be on the stack where do the jitting go? Will I have need of assembly; What changes are necessary, please? thank you.
-
Hi, I read some paper about how clr works on managed modules, managed heap and jit the managed assembly. That works on heap (reference type). It seems me that only the reference to those oblects are on the stack but the real objects are on the heap. Value type instead are allocate on the stack. I'm wondering what changes if also objects were allocate on the stack; what'll happen? If also objects will be on the stack where do the jitting go? Will I have need of assembly; What changes are necessary, please? thank you.
MarKus0 wrote:
I'm wondering what changes if also objects were allocate on the stack; what'll happen?
Nothing happens because object instances are NEVER allocated on the stack.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
MarKus0 wrote:
I'm wondering what changes if also objects were allocate on the stack; what'll happen?
Nothing happens because object instances are NEVER allocated on the stack.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Hi, I read some paper about how clr works on managed modules, managed heap and jit the managed assembly. That works on heap (reference type). It seems me that only the reference to those oblects are on the stack but the real objects are on the heap. Value type instead are allocate on the stack. I'm wondering what changes if also objects were allocate on the stack; what'll happen? If also objects will be on the stack where do the jitting go? Will I have need of assembly; What changes are necessary, please? thank you.
The very nature of a reference type excludes the possibility of it going on the stack. For example take this bit of code
public MyMethod(SomeObject obj)
{
MyReferenceType rt = new MyReferenceType(); // Assume this goes on the stack
obj.PropertyToKeep = rt;
// Method ends, the stack is unwinds as anything on it is taken off.
}Now, rt is destroyed at this point becuase the stack has shrunk. But, obj still maintains a reference to it. What happens? In C++ you would end up with a bad pointer that points to a piece of memory that no longer contains the object. The CLR simply doesn't allow this situation to occur in the first place.
Upcoming events: * Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... "I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless." My website
-
The very nature of a reference type excludes the possibility of it going on the stack. For example take this bit of code
public MyMethod(SomeObject obj)
{
MyReferenceType rt = new MyReferenceType(); // Assume this goes on the stack
obj.PropertyToKeep = rt;
// Method ends, the stack is unwinds as anything on it is taken off.
}Now, rt is destroyed at this point becuase the stack has shrunk. But, obj still maintains a reference to it. What happens? In C++ you would end up with a bad pointer that points to a piece of memory that no longer contains the object. The CLR simply doesn't allow this situation to occur in the first place.
Upcoming events: * Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... "I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless." My website
OK; I have to explain better. Focus on .NET C# (but it isn't the point of my question). I have to design a new CLR changing the actual CLR. My new CLR must allocate objects on the stack. So, how do I have to change the current CLR to allocate oblìjects on the stack? (probabily this new CLR doens't make sense (probabily because everythings goes on the stack)), but I need to think what I have to change to reach this aim... thanks
-
OK; I have to explain better. Focus on .NET C# (but it isn't the point of my question). I have to design a new CLR changing the actual CLR. My new CLR must allocate objects on the stack. So, how do I have to change the current CLR to allocate oblìjects on the stack? (probabily this new CLR doens't make sense (probabily because everythings goes on the stack)), but I need to think what I have to change to reach this aim... thanks
Make everything a value type?
Upcoming FREE developer events: * Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... * Reading: SQL Bits My website
-
Make everything a value type?
Upcoming FREE developer events: * Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... * Reading: SQL Bits My website
I don't know how....I'm thinking the way ( and after I'll can say if the thing is good or not). But what I want find is a solution that the CLR can manages objects on the stack instead on the heap. I know this hard/strange question....but will it be possible? I'm finding an rough idea (what'll do the loader...., the pointer, the Jit)...any idea?
-
I don't know how....I'm thinking the way ( and after I'll can say if the thing is good or not). But what I want find is a solution that the CLR can manages objects on the stack instead on the heap. I know this hard/strange question....but will it be possible? I'm finding an rough idea (what'll do the loader...., the pointer, the Jit)...any idea?
A stack is a data structure where things get added on one end, in a particular order, and get removed, at the same end, in reverse order. That is the only thing a stack is capable of (and it is very good at that). you can't allocate reference types on a stack: the stack is used for keeping track of program flow (calling and returning from methods) and for local value types (which live as long as the method is executing). If you return from a method, the stack is reset to the state it had when you entered the method, that is the only thing acceptable to the calling method. Ref types must live from construction (with new) until death (last reference got lost); they don't die in reverse order of construction, and they get constructed and die independent of program flow, hence there is no room whatsoever to allocate ref types on the stack. In summary: a system can not allocate ref types on the stack. It needs separate memory to hold them, such memory is called a heap. Actually ref types come from a couple of heaps, depending on the size of the objects (small objects get shuffled around to avoid heap fragmentation, large objects come from the large object heap, which is not reshuffled, and may get exhausted due to fragmentation, something Micro$oft tries not to focus your attention on). :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
A stack is a data structure where things get added on one end, in a particular order, and get removed, at the same end, in reverse order. That is the only thing a stack is capable of (and it is very good at that). you can't allocate reference types on a stack: the stack is used for keeping track of program flow (calling and returning from methods) and for local value types (which live as long as the method is executing). If you return from a method, the stack is reset to the state it had when you entered the method, that is the only thing acceptable to the calling method. Ref types must live from construction (with new) until death (last reference got lost); they don't die in reverse order of construction, and they get constructed and die independent of program flow, hence there is no room whatsoever to allocate ref types on the stack. In summary: a system can not allocate ref types on the stack. It needs separate memory to hold them, such memory is called a heap. Actually ref types come from a couple of heaps, depending on the size of the objects (small objects get shuffled around to avoid heap fragmentation, large objects come from the large object heap, which is not reshuffled, and may get exhausted due to fragmentation, something Micro$oft tries not to focus your attention on). :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
That was an excellent answer right up until
Luc Pattyn wrote:
Micro$oft
I hate that. Microsoft is a business. It is their job to make money and they happen to be very good at it.
Upcoming FREE developer events: * Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... * Reading: SQL Bits My website
-
I don't know how....I'm thinking the way ( and after I'll can say if the thing is good or not). But what I want find is a solution that the CLR can manages objects on the stack instead on the heap. I know this hard/strange question....but will it be possible? I'm finding an rough idea (what'll do the loader...., the pointer, the Jit)...any idea?
MarKus0 wrote:
but will it be possible?
No it won't. For the reasons Luc gave. This is a fundamental principle of the way stacks work in computer programs, and it has been pretty much since the first tiem a computer programmer created a subroutine.
Upcoming FREE developer events: * Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... * Reading: SQL Bits My website
-
yes, I know that. But the question was different: what changes should I do inside CLR if I want allocate object on the stack, what changes on the CLR Should I do? (I want change CLR for this, it's a theoretical question, my curiousity) thanks
You can't allocate objects on the stack because each position in the stack will only hold, on a 32-bit proc, a 32-bit VALUE. You can't allocate on object on the stack since an object can be any type, any size, and composed of one or more types, plus code. It's possible to convert an object to a serialized array of values that can be pushed onto the stack, but the method that you call would have to deserialize the data, recreate the object, and could then work it. But, that would defeat the entire purpose of putting it on the stack in the first place AND introduce a huge performance penality with the serialization/deserialzation process. I'm starting to question if you really know what the execution stack is and how it works.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
That was an excellent answer right up until
Luc Pattyn wrote:
Micro$oft
I hate that. Microsoft is a business. It is their job to make money and they happen to be very good at it.
Upcoming FREE developer events: * Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... * Reading: SQL Bits My website
Hi Colin,
Colin Angus Mackay wrote:
Microsoft is a business. It is their job to make money and they happen to be very good at it.
I agree. But I would like them to be a little better at offering things that make life easy for programmers/developers, even if that would (seem to) take away one percent of their profits. Why are line numbers not displayed by default in Visual source files ? Why does Windows show a silly error number when trying to run a .NET app on a system that does not have (the right version of) .NET installed ? Why don't they provide a full set of P/Invoke prototypes for all Win32 structures and functions ? Why does it take a network guru to set up a wireless network ? (are there any non-technical people who get any level of security?) Why do we have to view or enter stuff in 200*200 pixel windows and dropdowns, when the screen has over 1M pixel ? Why does most MSDN documentation on API stuff come without examples ? Why don't they provide a list of probable causes, in non-academic terms, for the most frequently occuring error situations ? ... the list is infinite. In general, is it so hard to listen to users and to read forums (like this one) and learn from it, as to how the user's experience could be improved (rather than just adding features, complexity and sometimes mystery). In my opinion most of what goes on on these forums should be made redundant by step-by-step improvements to the MS products and their documentation. Conclusion: as long as dollars/euros/yens seem to be more important than customers and their little problems, I tend to occasionally replace an 's' by a '$' Regards
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
Hi Colin,
Colin Angus Mackay wrote:
Microsoft is a business. It is their job to make money and they happen to be very good at it.
I agree. But I would like them to be a little better at offering things that make life easy for programmers/developers, even if that would (seem to) take away one percent of their profits. Why are line numbers not displayed by default in Visual source files ? Why does Windows show a silly error number when trying to run a .NET app on a system that does not have (the right version of) .NET installed ? Why don't they provide a full set of P/Invoke prototypes for all Win32 structures and functions ? Why does it take a network guru to set up a wireless network ? (are there any non-technical people who get any level of security?) Why do we have to view or enter stuff in 200*200 pixel windows and dropdowns, when the screen has over 1M pixel ? Why does most MSDN documentation on API stuff come without examples ? Why don't they provide a list of probable causes, in non-academic terms, for the most frequently occuring error situations ? ... the list is infinite. In general, is it so hard to listen to users and to read forums (like this one) and learn from it, as to how the user's experience could be improved (rather than just adding features, complexity and sometimes mystery). In my opinion most of what goes on on these forums should be made redundant by step-by-step improvements to the MS products and their documentation. Conclusion: as long as dollars/euros/yens seem to be more important than customers and their little problems, I tend to occasionally replace an 's' by a '$' Regards
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
Gosh! That's not what I see at all. Microsoft are very responsive for such a large company and they do try their best for the community. They are improving constantly, it just takes time. For instance, there are a lot more examples in MSDN than their used to be. There are a lot of new and innovative things on the horizon which I am sure will address some of your concerns.
Upcoming FREE developer events: * Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... * Reading: SQL Bits My website
-
A stack is a data structure where things get added on one end, in a particular order, and get removed, at the same end, in reverse order. That is the only thing a stack is capable of (and it is very good at that). you can't allocate reference types on a stack: the stack is used for keeping track of program flow (calling and returning from methods) and for local value types (which live as long as the method is executing). If you return from a method, the stack is reset to the state it had when you entered the method, that is the only thing acceptable to the calling method. Ref types must live from construction (with new) until death (last reference got lost); they don't die in reverse order of construction, and they get constructed and die independent of program flow, hence there is no room whatsoever to allocate ref types on the stack. In summary: a system can not allocate ref types on the stack. It needs separate memory to hold them, such memory is called a heap. Actually ref types come from a couple of heaps, depending on the size of the objects (small objects get shuffled around to avoid heap fragmentation, large objects come from the large object heap, which is not reshuffled, and may get exhausted due to fragmentation, something Micro$oft tries not to focus your attention on). :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
So, it's the OS that allocate space on the stack for the process?! If it's so, I think that can't exists a (new) CLR that manage stack..!? I understand that for my question, CLR would have to do the work of OS; so i would have to change OS too; is it that? Then arise one question on C#:
namespace Simple { class Program { static void Main(string[] args) { Console.WriteLine("that's the program"); int a = 0; myClass mc = new myClass(); } } }I read that every value type (int32, enumeration, and other) are on the stack; but if they're inside a class declaration they take part of object and then go on the heap. In c# even main is inside a class (in my example " Program"); with this knowledge, it seems to me that evey things goes on the heap. Could you explain to me what go on the stack ? (use my example code, please) Thanks... -
So, it's the OS that allocate space on the stack for the process?! If it's so, I think that can't exists a (new) CLR that manage stack..!? I understand that for my question, CLR would have to do the work of OS; so i would have to change OS too; is it that? Then arise one question on C#:
namespace Simple { class Program { static void Main(string[] args) { Console.WriteLine("that's the program"); int a = 0; myClass mc = new myClass(); } } }I read that every value type (int32, enumeration, and other) are on the stack; but if they're inside a class declaration they take part of object and then go on the heap. In c# even main is inside a class (in my example " Program"); with this knowledge, it seems to me that evey things goes on the heap. Could you explain to me what go on the stack ? (use my example code, please) Thanks...I already told you what goes on the stack, and why the other things don't fit on a stack. Things are the way they must be. For me the subject is closed. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
I already told you what goes on the stack, and why the other things don't fit on a stack. Things are the way they must be. For me the subject is closed. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
No - let him implement the OS as well. That should be worth seeing.
Deja View - the feeling that you've seen this post before.
-
No - let him implement the OS as well. That should be worth seeing.
Deja View - the feeling that you've seen this post before.
OK, on one condition, Chris should start a separate forum for it, since I expect a couple more discussion threads before the new OS is up and running...
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
So, it's the OS that allocate space on the stack for the process?! If it's so, I think that can't exists a (new) CLR that manage stack..!? I understand that for my question, CLR would have to do the work of OS; so i would have to change OS too; is it that? Then arise one question on C#:
namespace Simple { class Program { static void Main(string[] args) { Console.WriteLine("that's the program"); int a = 0; myClass mc = new myClass(); } } }I read that every value type (int32, enumeration, and other) are on the stack; but if they're inside a class declaration they take part of object and then go on the heap. In c# even main is inside a class (in my example " Program"); with this knowledge, it seems to me that evey things goes on the heap. Could you explain to me what go on the stack ? (use my example code, please) Thanks...MarKus0 wrote:
So, it's the OS that allocate space on the stack for the process?!
No, not entirely. The processor has a stack the is allocated on a per-thread basis. Ever here of the Stack Pointer? Read[^] It's the processor that's stopping you from doing what you want, not the .NET Framework or the O/S.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
OK, on one condition, Chris should start a separate forum for it, since I expect a couple more discussion threads before the new OS is up and running...
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
Seems fair. He'll need a cool name for the project though. How about calling it "Pillock" or "Idiot"? That way we can ask people "Are you running Idiot?"
Deja View - the feeling that you've seen this post before.
-
MarKus0 wrote:
So, it's the OS that allocate space on the stack for the process?!
No, not entirely. The processor has a stack the is allocated on a per-thread basis. Ever here of the Stack Pointer? Read[^] It's the processor that's stopping you from doing what you want, not the .NET Framework or the O/S.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Dave - don't let facts get in the way of our mocking him.
Deja View - the feeling that you've seen this post before.