[Vm-dev] mantis http://bugs.squeak.org/view.php?id=7349

Igor Stasenko siguctua at gmail.com
Wed May 6 17:35:52 UTC 2009


2009/5/6 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
>
> On Wed, May 6, 2009 at 8:28 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
>>
>> David T. Lewis wrote:
>>>
>>> The main concern seems to be existing bugs in the code base that are
>>> just now being exposed. I don't know of any easy way out; as far as
>>> I know you have to either inspect the code manually, or wait for it
>>> to fail at run time.
>>>
>>> Note, it is common in many plugins to pop things off the stack early
>>> in the method, so you cannot just patch the last line of the method.
>>> You need to check senders to determine the expected argument count,
>>> then make sure that the plugin matches this.
>>>
>>> SmartSyntaxInterpreterPlugin automates much of this, so it's less
>>> of a concern for plugins that use it. Also, I think that Eliot has
>>> some ideas for making the problem go away entirely.
>>
>> We changed our VMs to ignore push/pop requests from plugins and rather have the VM do the management of arguments. The VM interprets popXYZ as an access of method argument n-x and pushXYZ as an implicit return from a method and then pops the "right" number of args regardless of what the plugin thinks it requested. We also added more convenient (lef-to-right) argument accessors. This has worked very well for us.
>
> Yes, we support this in the Stack VM.  But this is sloooow, we're not actually using it yet, and I'm not supporting this for Cog.  I'm relying merely on the simple stack balance check which has also worked and is much faster.  This is only an error-checking step and doesnt have much benefit in production, whereas eliminating the bug in the first place by eliminating explicit stack manipulation in primitives is the way to go.

Except primitives who expecting any number of arguments, like
BlockClosure>>value. But this is rather an exception than a common
case.

>
>>
>> One thing we could do is for the next generation of VMs which have a new image format won't be referred to as Squeak 3x etc. to up the interpreter proxy major number and use only that mechanism. Thoughts?
>
> That a smart syntax approach is the way to go.  That it may be much better to duplicate primitives than support varargs (very few primitives need varargs) but that varargs can be supported somehow, e.g.
>     myVarArgClass: numArgs receiver: receiver with: firstArg
>         <varargs>
>         numArgs = 0 ifTrue: [^self fetchClassOf: receiver].
>         numArgs = 1 ifTrue: [^self fetchClassOf: firstArg].
>         ^self primitiveFailFor: BadNumArgs
> which would be both the class primitive and a "thisContext mirrorClassOf: something" primitive as the current one is:
>     primitiveClass
> | instance |
> instance := self stackTop.
> self pop: argumentCount+1 thenPush: (self fetchClassOf: instance)
>
> That one makes the common case go fast as long as errors are apparent.  So have as streamlined a mechanism that can still spot incorrect argument counts as possible, and hence that the best way is to make it impossible to get the argument count wrong in the first place by eliminating explicit stack manipulation in primitives.
>>
>> Cheers,
>>  - Andreas
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list