On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
cool we could turn them into nice query methods with semantics revealing names :)
I would just use a SHaredPool with class variables appropriately named, e.g.
SharedPool subclass: #VMParameterNames instanceVariableNames: '' classVariableNames: '... ImageFormatVersion ...'
VMParameterNames class methods for initialization initialize ... ImageFormatVersion := 41 ...
then a client would use things like
Smalltalk image vmParameterAt: ImageFormatVersion
These are for very special uses and I don't really like the idea of making access to them too easy.
On May 18, 2010, at 7:21 PM, Eliot Miranda wrote:
On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko siguctua@gmail.com
wrote:
2010/5/17 Eliot Miranda eliot.miranda@gmail.com:
On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
On Ma
bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog
also
uses bits 1 through 4 bit 0: 1 => open full screen, 0 => open using width & height bit 1: 1 => image floats are in little-endian format,
0=>
image floats are in big-endian format bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls
bit 3: 1 => set the flag bit on methods that the VMwill
only interpret (because they're considered too big to JIT) bit 4: 1 => preempting a process does not put it to
the
back of its run queue
I was not clear how to read bit 3: 1 this information is not in the compiledMethods?
For the Cog JIT I want to measure which methods get interpreted to
determine
the threshold at which to decide to JIT methods. It makes little sense
to
JIT methods that are large and only executed once, typically class initialization methods. A simple criterion is to set a limit on the
number
of literals in a method. But I still need to know whether my threshold
is
affecting frequently used methods. So I added the option of setting
the
flag bit in any method which the JIT refuses to compile because it has
too
many literals. Since I need to see which methods are interpreted on start-up putting a flag in the image header was convenient. The effect
is
that the JIT will set the flag bit on any method it refuses to JIT. I
can
then browse these in the image and decide whether any are important and adjust the threshold accordingly. Arguably this should be a command
line
argument, not an image header flag.
Eliot, i beg you, instead of using an obscure flags in image header, just add (or reserve unused) splObject indice and read/write whatever you want from there.
SOme times it isn't appropriate to put flags in the special objects
array. Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray. For all the flags which can be set in the header I provide access through vmParameterAt:[put:].
I guess that Cog having substantial changes all around places, so adding a convenient API for VM flags and removing a bit fiddling from image header, would make things transparent and easy to use from language side.
Ah, ok. That exists in vmParameterAt:[put:]. i.e. here's what's
different in vmParameterAt:put: at Teleplace:
VM parameters are numbered as follows: ... 4 allocationCount (read-only; nil in Cog VMs) 5 allocations between GCs (read-write; nil in CogVMs)
... 41 imageFormatVersion for the VM 42 number of stack pages in use (Cog Stack VM only,otherwise nil)
43 desired number of stack pages (stored in image fileheader, max 65535; Cog VMs only, otherwise nil)
44 size of eden, in bytes (Cog VMs only, otherwisenil)
45 desired size of eden, in bytes (stored in imagefile header; Cog VMs only, otherwise nil)
46 size of machine code zone, in bytes (stored inimage file header; Cog JIT VM only, otherwise nil)
47 desired size of machine code zone, in bytes(applies at startup only, stored in image file header; Cog JIT VM only)
48 various properties of the Cog VM as an integerencoding an array of bit flags.
Bit 0: implies the image's Process class hasthreadId as its 3rd inst var (zero relative)
Bit 1: if set, methods that are interpreted willhave the flag bit set in their header
Bit 2: if set, implies preempting a process doesnot put it to the back of its run queue
49-55 reserved for VM parameters that persist in the image(such as eden above)
56 number of process switches since startup(read-only)
57 number of ioProcessEvents calls since startup(read-only)
58 number of ForceInterruptCheck (Cog VMs) orquickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only)
59 number of check event calls since startup(read-only)
60 number of stack page overflows since startup(read-only; Cog VMs only)
61 number of stack page divorces since startup(read-only; Cog VMs only)
62 compiled code compactions since startup (read-only;Cog only; otherwise nil)
63 total milliseconds in compiled code compactionssince startup (read-only; Cog only; otherwise nil)
Stef
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 18 May 2010 22:17, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
cool we could turn them into nice query methods with semantics revealing names :)
I would just use a SHaredPool with class variables appropriately named, e.g. SharedPool subclass: #VMParameterNames instanceVariableNames: '' classVariableNames: '... ImageFormatVersion ...' VMParameterNames class methods for initialization initialize ... ImageFormatVersion := 41 ... then a client would use things like Smalltalk image vmParameterAt: ImageFormatVersion These are for very special uses and I don't really like the idea of making access to them too easy.
With such excuse, were ending up with a hacky shell scripts - an ultimately afwul way to access these attributes. It should be easier :)
Its been always easy to make a mess: Array setFormat: 88888. Array new. bye-bye vm & image.
Just give developers freedom, and then it is their own responsibility to not make mess out of it, not yours.
On 5/18/2010 1:36 PM, Igor Stasenko wrote:
With such excuse, were ending up with a hacky shell scripts - an ultimately afwul way to access these attributes. It should be easier :)
Its been always easy to make a mess: Array setFormat: 88888. Array new. bye-bye vm& image.
Just give developers freedom, and then it is their own responsibility to not make mess out of it, not yours.
This isn't about "making a mess", it's about responsibilities. Currently, the VM and only the VM is responsible for handling the image file. This has several advantages because it allows some rather unsual 'file handling' on some platforms like Android (where there's not even an image file per se). Contrary to which, computing the class format is something that is within the responsibility of the image and not the VM.
Of course, that could be changed - we could have some 'self-writing' and even 'self-reading' image code (the latter is a bit tricky, but not too much actually) that relieves the VM from having to ever read or write an image file, and that would be fine. But the point here is that the current distribution of responsibilities is such that the VM owns that part and it's got absolutely nothing to do with 'developers freedom' (you can after all change the VM!).
Cheers, - Andreas
On 19 May 2010 00:31, Andreas Raab andreas.raab@gmx.de wrote:
On 5/18/2010 1:36 PM, Igor Stasenko wrote:
With such excuse, were ending up with a hacky shell scripts - an ultimately afwul way to access these attributes. It should be easier :)
Its been always easy to make a mess: Array setFormat: 88888. Array new. bye-bye vm& image.
Just give developers freedom, and then it is their own responsibility to not make mess out of it, not yours.
This isn't about "making a mess", it's about responsibilities. Currently, the VM and only the VM is responsible for handling the image file. This has several advantages because it allows some rather unsual 'file handling' on some platforms like Android (where there's not even an image file per se). Contrary to which, computing the class format is something that is within the responsibility of the image and not the VM.
Of course, that could be changed - we could have some 'self-writing' and even 'self-reading' image code (the latter is a bit tricky, but not too much actually) that relieves the VM from having to ever read or write an image file, and that would be fine. But the point here is that the current distribution of responsibilities is such that the VM owns that part and it's got absolutely nothing to do with 'developers freedom' (you can after all change the VM!).
The problem, as i see it, that VM needs a set of startup options, either for bootstrapping interpreter's state or its modules, like display , network etc. So as VM evolves and develops, you may require some new options. And once you need that, a question arises: where you should put that, and who is responsible for initializing them etc etc.. so you adding a bunch of C code in addition to existing bloat.
As i already repeated , multiple times, my vision is that VM should be stupid and primitive as much as possible. Whenever some operation requires some non-trivial logics, this should belong to a language side. In this way, i verifying all my ideas concerning changes to VM against this rule of thumb. If it doesn't pass that rule, then i doing things wrong.
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.
So, my point is to keep a bare minimum options in image header, while rest should use a uniform API, easy to use at both VM and language side. Then adding an extra option won't cause you much pain.
Once you having an access to image file (or a bulk memory region), technically, there is no problem, where these options located, once you have a standartized way how to extract them.
Saving an image with new set of options/header is merery a question of providing an additional argument to primitive, as simple as self snapshotPrimitive: options instead of self snapshotPrimitive
I'm not saying that the above is best approach. But as i said, the better is one which makes VM less clever and more stupid, leaving the language side to decide what to do and when.
Cheers, - Andreas
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
On 19 May 2010 03:40, Andreas Raab andreas.raab@gmx.de wrote:
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.
Image having a lot of places which require you to be very careful: - bitblt & canvas code - morphic event handling - compiler & debugger - processes, semaphores etc - ... many many other places
so, by following your logic, since its unsafe to alter the behavior in these places, then they should be moved to C code? A JIT is an exceptional example , mainly it is something, which you can't do without low-level access to machinery.
What i don't like to happen is to see that eventually all smalltalk code consists from lines like:
result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz andDontForgetAbout: zork andRideAPonyWith: that.
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'.
Right.
Cheers, - Andreas
On 5/18/2010 5:58 PM, Igor Stasenko wrote:
On 19 May 2010 03:40, Andreas Raabandreas.raab@gmx.de wrote:
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.
Image having a lot of places which require you to be very careful:
- bitblt& canvas code
- morphic event handling
- compiler& debugger
- processes, semaphores etc
- ... many many other places
so, by following your logic, since its unsafe to alter the behavior in these places, then they should be moved to C code?
Of course not. You can always program yourself into a corner where there's no way out. It's a matter of the expected failure mode. When I use the term 'safety' I mean mostly referential integrity. In other words memory safety.
For example, the reason why I'm not in favor of advocating the use of the FFI instead of the use of plugins is that when using the FFI people do not understand what could go wrong because they don't understand the concepts of the underlying platform. However, when you write a plugin you're proving that at least you know how to use C and usually this means you know *something* about the related set of issues.
And of course, when the very same people who have no clue about C and memory management corrupt their heap by the use of the FFI you get these complaints about how 'unstable' the system is. How very ironic.
In any case, my definition of 'safety' is not the same you're implying above. It mostly relates to memory safety.
BTW, many of the sticky points you're mentioning could be fixed by having a 'panic' button for the VM that simply suspends all processes and fires up a single new process to listen on a port and take commands. SSH into the image and you can see what you can repair. And yet again, it's the VM that provides the way out here because your in-image handling of the panic button could already be compromised.
What i don't like to happen is to see that eventually all smalltalk code consists from lines like:
result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz andDontForgetAbout: zork andRideAPonyWith: that.
That's called a 'glue' or 'scripting' language. Python is having dramatic success with effectively just that.
Cheers, - Andreas
On 19 May 2010 04:38, Andreas Raab andreas.raab@gmx.de wrote:
On 5/18/2010 5:58 PM, Igor Stasenko wrote:
On 19 May 2010 03:40, Andreas Raabandreas.raab@gmx.de wrote:
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.
Image having a lot of places which require you to be very careful: - bitblt& canvas code - morphic event handling - compiler& debugger - processes, semaphores etc - ... many many other places
so, by following your logic, since its unsafe to alter the behavior in these places, then they should be moved to C code?
Of course not. You can always program yourself into a corner where there's no way out. It's a matter of the expected failure mode. When I use the term 'safety' I mean mostly referential integrity. In other words memory safety.
ok.
For example, the reason why I'm not in favor of advocating the use of the FFI instead of the use of plugins is that when using the FFI people do not understand what could go wrong because they don't understand the concepts of the underlying platform. However, when you write a plugin you're proving that at least you know how to use C and usually this means you know *something* about the related set of issues.
And of course, when the very same people who have no clue about C and memory management corrupt their heap by the use of the FFI you get these complaints about how 'unstable' the system is. How very ironic.
That's not ironic. That's plain stupid. If people using FFI, and don't realizing what is 'direct memory access', and all consequences of it, then you will simply waste your time arguing with them about 'safety', whatever meaning they putting in it.
But i doubt you'll find such people. The point is, that there always should be a wrapping layer, written either in form of plugin or using FFI , which provides such safety. And i don't care, which language used to implement that - smalltalk or C. In both you have a very same chances to do stupid things and crash your system. Except that with FFI, you don't need to recompile plugin/VM each time you fixed the bug.
In any case, my definition of 'safety' is not the same you're implying above. It mostly relates to memory safety.
BTW, many of the sticky points you're mentioning could be fixed by having a 'panic' button for the VM that simply suspends all processes and fires up a single new process to listen on a port and take commands. SSH into the image and you can see what you can repair. And yet again, it's the VM that provides the way out here because your in-image handling of the panic button could already be compromised.
panic button won't help if you do Array setFormat: 88888. or Object become: nil.
So, i'd rather focus on a such design, where direct manipulation with critical parts of environment is sufficiently guarded against fools, by using safety wrappers or multi-level capability-based mechanisms.
What i don't like to happen is to see that eventually all smalltalk code consists from lines like:
result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz andDontForgetAbout: zork andRideAPonyWith: that.
That's called a 'glue' or 'scripting' language. Python is having dramatic success with effectively just that.
Yeah.. scripting language is cool, when you having a host application, specialized in doing something good, and leaving a window of flexibility by providing scripting frontend. But VM is apparently wrong place for that.
If you would ask me, how one could use smalltalk for scripting , then first thing, what we should do is to change VM to be a dynamically loadable library, with nice and consistent API. And, obviously, everything except interpreter should be separated from VM core. There should be no windowing, events, networking and many other things , which hardcoded by default in current VM. A host application should be able to easily provide own, in case of need.
Cheers, - Andreas
P.S. by any means, if we want squeak to serve as a tool for professionals, lets grow up and make VM for professionals, where they would be easily able to do things, without much fuss. But if we treat an interpreted language as a kinder-garden for childs, where they can do whatever they want with their toys, without nuking a planet, then they'll never grow up, because being grown up means taking responsibility for own actions, and no parental control, who could save you from your own mistakes and buy you a new toy.
On 19 May 2010 05:41, Igor Stasenko siguctua@gmail.com wrote:
On 19 May 2010 04:38, Andreas Raab andreas.raab@gmx.de wrote:
On 5/18/2010 5:58 PM, Igor Stasenko wrote:
On 19 May 2010 03:40, Andreas Raabandreas.raab@gmx.de wrote:
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.
Image having a lot of places which require you to be very careful: - bitblt& canvas code - morphic event handling - compiler& debugger - processes, semaphores etc - ... many many other places
so, by following your logic, since its unsafe to alter the behavior in these places, then they should be moved to C code?
Of course not. You can always program yourself into a corner where there's no way out. It's a matter of the expected failure mode. When I use the term 'safety' I mean mostly referential integrity. In other words memory safety.
ok.
For example, the reason why I'm not in favor of advocating the use of the FFI instead of the use of plugins is that when using the FFI people do not understand what could go wrong because they don't understand the concepts of the underlying platform. However, when you write a plugin you're proving that at least you know how to use C and usually this means you know *something* about the related set of issues.
And of course, when the very same people who have no clue about C and memory management corrupt their heap by the use of the FFI you get these complaints about how 'unstable' the system is. How very ironic.
That's not ironic. That's plain stupid. If people using FFI, and don't realizing what is 'direct memory access', and all consequences of it, then you will simply waste your time arguing with them about 'safety', whatever meaning they putting in it.
But i doubt you'll find such people. The point is, that there always should be a wrapping layer, written either in form of plugin or using FFI , which provides such safety. And i don't care, which language used to implement that - smalltalk or C. In both you have a very same chances to do stupid things and crash your system. Except that with FFI, you don't need to recompile plugin/VM each time you fixed the bug.
In any case, my definition of 'safety' is not the same you're implying above. It mostly relates to memory safety.
BTW, many of the sticky points you're mentioning could be fixed by having a 'panic' button for the VM that simply suspends all processes and fires up a single new process to listen on a port and take commands. SSH into the image and you can see what you can repair. And yet again, it's the VM that provides the way out here because your in-image handling of the panic button could already be compromised.
panic button won't help if you do Array setFormat: 88888. or Object become: nil.
So, i'd rather focus on a such design, where direct manipulation with critical parts of environment is sufficiently guarded against fools, by using safety wrappers or multi-level capability-based mechanisms.
What i don't like to happen is to see that eventually all smalltalk code consists from lines like:
result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz andDontForgetAbout: zork andRideAPonyWith: that.
That's called a 'glue' or 'scripting' language. Python is having dramatic success with effectively just that.
Yeah.. scripting language is cool, when you having a host application, specialized in doing something good, and leaving a window of flexibility by providing scripting frontend. But VM is apparently wrong place for that.
If you would ask me, how one could use smalltalk for scripting , then first thing, what we should do is to change VM to be a dynamically loadable library, with nice and consistent API. And, obviously, everything except interpreter should be separated from VM core. There should be no windowing, events, networking and many other things , which hardcoded by default in current VM. A host application should be able to easily provide own, in case of need.
Cheers, - Andreas
-- Best regards, Igor Stasenko AKA sig.
On 5/18/2010 7:57 PM, Igor Stasenko wrote:
P.S. by any means, if we want squeak to serve as a tool for professionals, lets grow up and make VM for professionals, where they would be easily able to do things, without much fuss. But if we treat an interpreted language as a kinder-garden for childs, where they can do whatever they want with their toys, without nuking a planet, then they'll never grow up, because being grown up means taking responsibility for own actions, and no parental control, who could save you from your own mistakes and buy you a new toy.
Can we please disagree without this silly polemic?
Cheers, - Andreas
On 19 May 2010 05:41, Igor Stasenkosiguctua@gmail.com wrote:
On 19 May 2010 04:38, Andreas Raabandreas.raab@gmx.de wrote:
On 5/18/2010 5:58 PM, Igor Stasenko wrote:
On 19 May 2010 03:40, Andreas Raabandreas.raab@gmx.de wrote:
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.
Image having a lot of places which require you to be very careful:
- bitblt& canvas code
- morphic event handling
- compiler& debugger
- processes, semaphores etc
- ... many many other places
so, by following your logic, since its unsafe to alter the behavior in these places, then they should be moved to C code?
Of course not. You can always program yourself into a corner where there's no way out. It's a matter of the expected failure mode. When I use the term 'safety' I mean mostly referential integrity. In other words memory safety.
ok.
For example, the reason why I'm not in favor of advocating the use of the FFI instead of the use of plugins is that when using the FFI people do not understand what could go wrong because they don't understand the concepts of the underlying platform. However, when you write a plugin you're proving that at least you know how to use C and usually this means you know *something* about the related set of issues.
And of course, when the very same people who have no clue about C and memory management corrupt their heap by the use of the FFI you get these complaints about how 'unstable' the system is. How very ironic.
That's not ironic. That's plain stupid. If people using FFI, and don't realizing what is 'direct memory access', and all consequences of it, then you will simply waste your time arguing with them about 'safety', whatever meaning they putting in it.
But i doubt you'll find such people. The point is, that there always should be a wrapping layer, written either in form of plugin or using FFI , which provides such safety. And i don't care, which language used to implement that - smalltalk or C. In both you have a very same chances to do stupid things and crash your system. Except that with FFI, you don't need to recompile plugin/VM each time you fixed the bug.
In any case, my definition of 'safety' is not the same you're implying above. It mostly relates to memory safety.
BTW, many of the sticky points you're mentioning could be fixed by having a 'panic' button for the VM that simply suspends all processes and fires up a single new process to listen on a port and take commands. SSH into the image and you can see what you can repair. And yet again, it's the VM that provides the way out here because your in-image handling of the panic button could already be compromised.
panic button won't help if you do Array setFormat: 88888. or Object become: nil.
So, i'd rather focus on a such design, where direct manipulation with critical parts of environment is sufficiently guarded against fools, by using safety wrappers or multi-level capability-based mechanisms.
What i don't like to happen is to see that eventually all smalltalk code consists from lines like:
result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz andDontForgetAbout: zork andRideAPonyWith: that.
That's called a 'glue' or 'scripting' language. Python is having dramatic success with effectively just that.
Yeah.. scripting language is cool, when you having a host application, specialized in doing something good, and leaving a window of flexibility by providing scripting frontend. But VM is apparently wrong place for that.
If you would ask me, how one could use smalltalk for scripting , then first thing, what we should do is to change VM to be a dynamically loadable library, with nice and consistent API. And, obviously, everything except interpreter should be separated from VM core. There should be no windowing, events, networking and many other things , which hardcoded by default in current VM. A host application should be able to easily provide own, in case of need.
Cheers,
- Andreas
-- Best regards, Igor Stasenko AKA sig.
On 5/18/2010 7:41 PM, Igor Stasenko wrote:
On 19 May 2010 04:38, Andreas Raabandreas.raab@gmx.de wrote:
And of course, when the very same people who have no clue about C and memory management corrupt their heap by the use of the FFI you get these complaints about how 'unstable' the system is. How very ironic.
That's not ironic. That's plain stupid. If people using FFI, and don't realizing what is 'direct memory access', and all consequences of it, then you will simply waste your time arguing with them about 'safety', whatever meaning they putting in it.
But i doubt you'll find such people. The point is, that there always should be a wrapping layer, written either in form of plugin or using FFI , which provides such safety.
See, this is where you're wrong. These problems are never *that* simple. If the stuff just crashes it'd be trivial to find. It's like concurrency bugs - when they're outright broken they're usually broken in 'easy' ways. However, the problems often show in forms where the system crashes unreproducibly two days before ship date. And the only way to work through this stuff is by proving yourself that the problem can't be here or there and to narrow it down to a place where you have a chance to find it.
To give an example, for a long time we had apparently random VM crashes due to using vertex arrays in OpenGL. The code was as simple as one could think; just pushing the gl[Vertex|Color|Normal]Pointers into the context and call glDrawArrays. We found that this would crash because (as the name implies) the state is 'client' state and the GL actually keeps a pointer to the data. So if the operations would be interrupted by a process switch, if that process would cause a (full) GC, and if that GC would collect enough data to free that memory region, then and only then it would crash. This is how these problems show; there's nothing outright 'stupid' about it. BTW, the solution: Moving the entire operation into a plugin so that all of it is atomic.
In any case, my definition of 'safety' is not the same you're implying above. It mostly relates to memory safety.
BTW, many of the sticky points you're mentioning could be fixed by having a 'panic' button for the VM that simply suspends all processes and fires up a single new process to listen on a port and take commands. SSH into the image and you can see what you can repair. And yet again, it's the VM that provides the way out here because your in-image handling of the panic button could already be compromised.
panic button won't help if you do Array setFormat: 88888. or Object become: nil.
Sure. I never said there'd be perfect safety. There's no such thing. But that doesn't mean you shouldn't try to improve things. And a panic button could make many situations much less problematic than they are today. But the point here really is that by having the VM, instead of the image, do that, you get a level of indirection that can help fixing the broken parts.
So, i'd rather focus on a such design, where direct manipulation with critical parts of environment is sufficiently guarded against fools, by using safety wrappers or multi-level capability-based mechanisms.
If you know how to use that to ensure that you're not dereferencing an invalid pointer I'm all ears. Seriously. If there's a safe way to use that stuff I'd love to use it.
I should also point out that there *are* ways to do that safely. It depends on whether the thing you're talking to is memory safe or not. In our products we ship a Python bridge where you talk from Squeak to Python and back. That bridge is safe and I have no problems exposing it because it's objects on either end. You never get your hands on a 'pointer' you only get our hands on a Python object in Squeak or a Squeak object in Python that you can send messages to. Since Python is GCed as well the bridge comes down to a bit of mapping between Squeak and Python objects and after that's it's a complete and open free-for-all (incl. callbacks, error propagation and more).
I'm completely game for a similar bridge to Java or .NET or any other memory safe object system. It's that memory unsafe stuff that I object to.
If you would ask me, how one could use smalltalk for scripting , then first thing, what we should do is to change VM to be a dynamically loadable library, with nice and consistent API.
Yes, indeed. When I wrote the bridge it was quite an eye opener. Both sides provide the same basic stuff, but what a difference in the interface! Clearly, the Python folks designed theirs to be used from C/C++ and clearly, we didn't ;-)
Cheers, - Andreas
On 19 May 2010 07:16, Andreas Raab andreas.raab@gmx.de wrote:
On 5/18/2010 7:41 PM, Igor Stasenko wrote:
On 19 May 2010 04:38, Andreas Raabandreas.raab@gmx.de wrote:
And of course, when the very same people who have no clue about C and memory management corrupt their heap by the use of the FFI you get these complaints about how 'unstable' the system is. How very ironic.
That's not ironic. That's plain stupid. If people using FFI, and don't realizing what is 'direct memory access', and all consequences of it, then you will simply waste your time arguing with them about 'safety', whatever meaning they putting in it.
But i doubt you'll find such people. The point is, that there always should be a wrapping layer, written either in form of plugin or using FFI , which provides such safety.
See, this is where you're wrong. These problems are never *that* simple. If the stuff just crashes it'd be trivial to find. It's like concurrency bugs - when they're outright broken they're usually broken in 'easy' ways. However, the problems often show in forms where the system crashes unreproducibly two days before ship date. And the only way to work through this stuff is by proving yourself that the problem can't be here or there and to narrow it down to a place where you have a chance to find it.
To give an example, for a long time we had apparently random VM crashes due to using vertex arrays in OpenGL. The code was as simple as one could think; just pushing the gl[Vertex|Color|Normal]Pointers into the context and call glDrawArrays. We found that this would crash because (as the name implies) the state is 'client' state and the GL actually keeps a pointer to the data. So if the operations would be interrupted by a process switch, if that process would cause a (full) GC, and if that GC would collect enough data to free that memory region, then and only then it would crash. This is how these problems show; there's nothing outright 'stupid' about it. BTW, the solution: Moving the entire operation into a plugin so that all of it is atomic.
i see. Its because you can't make a multiple FFI calls in a row primitively(atomically). And whenever you doing this using multiple sends, there's always a chance to interrupt it and this is where GC comes in play. :) Good example. But you could meet with same problem, if you would blindly implement separate gl[Vertex|Color|Normal]Pointers and glDrawArrays primitives, instead of a single glDrawArrays: vertexBufer colors: colorBuffer normals: normalBuffer attibs: attribBuffer ...
And i don't think that going into VM you are automatically free from such mistakes.
With NB, i could implement such primitive in image. And this is where enabling even more 'unsafety' would bring you more safety in the end :) Because when you know clearly, what you should do (safely), you will do it anyways, no matter what it takes. But then difference lies in other plane: how much effort and time it takes to implement it and integrate it into your application.
I implemented multiple VM plugins, over a time, and i wouldn't say that i happy with this process. You have to (re)build VM each time, then you have to make sure that interfaces match between image side code and plugin, and then you have to guess , what go wrong if your prim fails.. so, its a whole adventure for brave & dedicated people. Shipping your code is next story: - ahh.. so, you made VM modifications? Bummer. - Get back when you have your changes integrated for all platforms & available in standard VM package.
In any case, my definition of 'safety' is not the same you're implying above. It mostly relates to memory safety.
BTW, many of the sticky points you're mentioning could be fixed by having a 'panic' button for the VM that simply suspends all processes and fires up a single new process to listen on a port and take commands. SSH into the image and you can see what you can repair. And yet again, it's the VM that provides the way out here because your in-image handling of the panic button could already be compromised.
panic button won't help if you do Array setFormat: 88888. or Object become: nil.
Sure. I never said there'd be perfect safety. There's no such thing. But that doesn't mean you shouldn't try to improve things. And a panic button could make many situations much less problematic than they are today. But the point here really is that by having the VM, instead of the image, do that, you get a level of indirection that can help fixing the broken parts.
So, i'd rather focus on a such design, where direct manipulation with critical parts of environment is sufficiently guarded against fools, by using safety wrappers or multi-level capability-based mechanisms.
If you know how to use that to ensure that you're not dereferencing an invalid pointer I'm all ears. Seriously. If there's a safe way to use that stuff I'd love to use it.
On windoze you could check if read/write at given memory region would cause GP fault. But checking that will cost you additional cycles, of course.
Insted of that, i think its better to use structured exception handlers, so, you can catch GP faults and return into image as prim failure.
I should also point out that there *are* ways to do that safely. It depends on whether the thing you're talking to is memory safe or not. In our products we ship a Python bridge where you talk from Squeak to Python and back. That bridge is safe and I have no problems exposing it because it's objects on either end. You never get your hands on a 'pointer' you only get our hands on a Python object in Squeak or a Squeak object in Python that you can send messages to. Since Python is GCed as well the bridge comes down to a bit of mapping between Squeak and Python objects and after that's it's a complete and open free-for-all (incl. callbacks, error propagation and more).
I'm completely game for a similar bridge to Java or .NET or any other memory safe object system. It's that memory unsafe stuff that I object to.
Yeah, but unfortunately, C world is still there, behind the cover of all such 'memory safety' :) Not to mention, that there a tons of different libraries having no 'objects', but a raw C interfaces with all these raw pointers and such... But, again, once you need an access to some exact foreign interface the safety is on second plane, because first problem you need to solve is: how fast you could integrate it, how much time will pass between starting it, and running a first piece of code, which does what you need. Only then, you can start testing and working on the safety measures.
So, i would say, that the faster you can fail (which means you already in testing stage), the better. :)
If you would ask me, how one could use smalltalk for scripting , then first thing, what we should do is to change VM to be a dynamically loadable library, with nice and consistent API.
Yes, indeed. When I wrote the bridge it was quite an eye opener. Both sides provide the same basic stuff, but what a difference in the interface! Clearly, the Python folks designed theirs to be used from C/C++ and clearly, we didn't ;-)
Cheers, - Andreas
first thanks for the discussion it was really interesting.
If you would ask me, how one could use smalltalk for scripting , then
first thing, what we should do is to change VM to be a dynamically loadable library, with nice and consistent API.
Yes, indeed. When I wrote the bridge it was quite an eye opener. Both sides provide the same basic stuff, but what a difference in the interface! Clearly, the Python folks designed theirs to be used from C/C++ and clearly, we didn't ;-)
Andreas do you see a chance that the vm slowly moves in that direction because this is an important point for the future. When I see lua getting embedded in a lot of cool app.
Stef
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Eliot Miranda -
Igor Stasenko -
stephane ducasse