dotnet clr: We would like to extend a virtual machine as CLR or JVM to allow
objects allocation on stack and on heap. What are the repercussions on
the architecture
caused by this modification?

What problem it could imply?

[quoted text, click to view]

I realize that I'm not answering the question that you posed but I'd like to
point out that the VS.Net 2005 language C++/CLI lets you do this in a way.
When an object "allocated" on the stack goes out of scope its destructor
runs which brings deterministic finalization to a .Net language. I put
allocated in quotes because, IIUC, the underlying object isn't really
allocated on the stack, it will get garbage collected eventually like
everything else, but rather compiler sleight of hand.

Regards,
Will

[quoted text, click to view]

Well, the most obvious problems:

1) What happens when you return a reference to an object which was
allocated on the stack in the method which returns it?

2) What happens when a reference is stored as an instance/static
variable, but the object then vanishes, being on the stack?

3) How can multiple threads access data which is on the stack of one
particular thread?

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet

[quoted text, click to view]

Could you explain me these problems?

[quoted text, click to view]

Well, what's not clear? They all basically involve one piece of code
having a reference to an object which was created in a stack frame
which may no longer exist.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet