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

[Igor Stasenko]

On 19 May 2010 07:16, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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.
>

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
>



-- 
Best regards,
Igor Stasenko AKA sig.