On 21 March 2011 21:14, Eliot Miranda <[email protected]> wrote: > > > On Mon, Mar 21, 2011 at 12:13 PM, Mariano Martinez Peck > <[email protected]> wrote: >> >> >> On Mon, Mar 21, 2011 at 7:23 PM, Stéphane Ducasse >> <[email protected]> wrote: >>> >>> This would be a nice little topic... this bytecode verifier. >> >> Probably on top of Opal > > The bytecode verifier must be in the VM. If it is up in the image it can be > side-stepped. The VM is the ultimate executor of code and so it must apply > verification. It could be written in Smalltalk and verified in Smalltalk > and then translated. But it must be part of the VM and used by the VM > before running any previously unverified method.
indeed > best, > Eliot >> >> >>> >>> Stef >>> >>> On Mar 21, 2011, at 2:57 PM, Toon Verwaest wrote: >>> >>> > Yes you are right! Bytecode validation would be very important here. If >>> > you ask me, the VM should only allow verified bytecode to be executed. >>> > Here >>> > it could have a dual model, where bytecodes are "internalized" whenever >>> > you >>> > give them to the VM first. At that point they are validated. Once it's >>> > internalized, it can't be modified anymore from the outside, since the >>> > Smalltalk world doesn't have direct access to the internalized version. >>> > All >>> > changes to the bytecode "source", needs to be propagated to the VM by >>> > re-internalizing it. >>> > >>> > This is exactly the model I'm using in Pinocchio... and that allows us >>> > to not use bytecodes in the first place :) You just need a way to map the >>> > internal version back onto the highlevel version for debugging. (We don't >>> > verify the bytecode yet though). >>> > >>> > Bytecode verification btw shouldn't be too hard. You just need to make >>> > sure that all the codes are safe for the instance at hand, and for the >>> > method contexts you create. Anything else is just a runtime semantical >>> > error >>> > which you can't guarantee, since you don't know what the programmer is >>> > trying to do. We don't verify it yet since I'm still designing my >>> > register-based bytecodes; and since I atm have too much work at hand :) >>> > >>> > cheers, >>> > Toon >>> > >>> > On 03/21/2011 02:22 PM, Igor Stasenko wrote: >>> >> On 21 March 2011 13:14, Toon Verwaest<[email protected]> wrote: >>> >>> I couldn't agree more! >>> >>> >>> >>> However, here the problem is not that the format isn't a correct >>> >>> format. The >>> >>> problem is that a bytecode is activated that is incompatible with the >>> >>> instance format. So basically on every bytecode accessing an instance >>> >>> you >>> >>> would have to check if this is a valid access. And as we all know, >>> >>> Smalltalk >>> >>> avoids this; it makes things faster :) >>> >>> >>> >> In other words, a responsibility of having correct bytecode lies on >>> >> image side, not on VM side. >>> >> >>> >> Adding a bytecode verifier to VM will be a lot of work.. And of course >>> >> it could verify it only when you installing a method, >>> >> not when you activating it. >>> >> >>> >>> Toon >>> >>> >>> >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote: >>> >>>> On 21 March 2011 11:29, Tudor Girba<[email protected]> wrote: >>> >>>>> Thanks, Toon! >>> >>>>> >>> >>>>> I changed the code to explicitly set the format, and it seems to >>> >>>>> fix the >>> >>>>> problem: >>> >>>>> >>> >>>>> cls := Class new superclass: MooseElement; >>> >>>>> setFormat: MooseElement format; >>> >>>>> yourself. >>> >>>>> cls compileSilently: 'mooseName ^ 1/0'. >>> >>>>> element := cls new. >>> >>>>> >>> >>>>> Is this correct? >>> >>>>> >>> >>>> Yes, you should pay attention to have correct format. >>> >>>> But of course VM could also be more cautios and verify if your >>> >>>> class >>> >>>> are well formed before creating an instance of it.. >>> >>>> >>> >>>> >>> >>>> >>> >>>>> Cheers, >>> >>>>> Doru >>> >>>>> >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >>> > >>> > >>> >>> >> > > -- Best regards, Igor Stasenko AKA sig.
