[Vm-dev] Re: [Pharo-project] how to change the default size of the Pharo host windows?

[Andreas Raab]

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 
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