On 5/18/2010 5:06 PM, Igor Stasenko wrote:
As i already repeated , multiple times, my vision is that VM should be stupid and primitive as much as possible.
And I have often pointed out that I do not share that vision.
My idea of the VM is that it provides a safe abstraction layer in which it is hard to break anything so I can experiment freely and without fear of losing my valuable data. Since I'm not a language bigot, I don't mind dropping into C for the weird stuff. It actually suits me fine as a reminder that I'm entering unsafe grounds where I need to go slowly and carefully because even the most superficial error will crash me beyond a means of recovery. That's for example why I like JITs and why I like stuff like context-to-stack mapping; it provides a safe ground where I'm allowed to make mistakes without being unduly punished for a mere typo.
My point, that we should put these responsibilities up to language side: whether use display or not, what modules to load or not, what initial display size should be , etc etc. Then you having all levers of control at language side, and VM is basically serving your requests, unlike the current situation, when you often finding out, that there is no way how you could tell VM to use different option(s) , except from passing arguments from command line or altering an image file using hacky scripts.
There are ways of doing this properly. You can add the abstractions to the VM; it's not that the VM is not accessible. Your snapshot primitive is actually just such an abstraction - instead of reading and writing 'header bits' you are passing a set of options that the VM can interpret in any way it sees fit. That is an abstraction which still keeps the handling of the image file itself plainly in the VM - the VM can decide (for example) to store such options on Android in a completely different place than 'the image file'.
Cheers, - Andreas