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

Eliot Miranda eliot.miranda at gmail.com
Wed May 6 16:13:08 UTC 2009

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.

> 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
        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:
| 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090506/b0e570f6/attachment-0001.htm

More information about the Vm-dev mailing list