[Vm-dev] Re: [Pharo-project] how to change the default size of
the Pharo host windows?
andreas.raab at gmx.de
Wed May 19 04:16:11 UTC 2010
On 5/18/2010 7:41 PM, Igor Stasenko wrote:
> On 19 May 2010 04:38, Andreas Raab<andreas.raab at 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
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 ;-)
More information about the Vm-dev