[Vm-dev] Re: SmallInetger as methods was not ready yet....now
eliot.miranda at gmail.com
Sat Dec 4 00:18:34 UTC 2010
On Fri, Dec 3, 2010 at 10:15 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 12/3/2010 10:07 AM, Igor Stasenko wrote:
>> On 3 December 2010 19:02, Andreas Raab<andreas.raab at gmx.de> wrote:
>>> maybe supporting SmallInteger as methods was not a good idea :(
>>> FWIW, Objects as methods weren't intended for SmallInts; they were
>>> for stuff like method wrappers. Using SmallIntegers for methods is a hack
>>> and I'm not surprised it doesn't work. But it is easy to fix - just wrap
>>> your ints into something else and you're good to go.
>> clearly, VM should not crash if it finds smallint in method dictionary.
>> Of course, it may 'not work', but in less destructive way.
> Well, there are limits. By the same argument you can come up with any
> number of things that currently crash the VM where one might say the VM
> should react in a less destructive way (thisContext swapSender: 0 anyone?).
> Performance is important in this area and having to throw in a bunch of
> checks all over the place is something that I'm not to fond of.
Well, if the vm supports "objects as methods" then there needs to be a check
for something fetched from a method dictionary being a CompiledMethod
somewhere. It is easy to make this robust in the face of SmallIntegers.
The elegance is in writing the code so that the check occurs in as few
places as possible. In my current Cog I've managed to get this down to two
places in the normal lookup machinery, addNewMethodToCache: for the
interpreter and lookupAndCog:for: for inline cache misses. Primitives
like primitiveDoNamedPrimitiveWithArgs and primitiveExecuteMethodArgsArray
need to check also (5 in all in Cog) but for the normal lookup machinery
things feel OK.
BTW, Mariano's use of SmallIntegers rather than wrappers is an attempt to
get a very compact image and seems a reasonable experiment. Using wrappers
would defeat his use-as-little-memory-as-possible purpose.
> If you really want to do something here I'd do it entirely differently: Add
> a primitive to the VM that can answer the question "can you execute this
> object?" and use it before adding something to the method dictionary. That
> way you won't be able to create a method dictionary that contains stuff
> which is not executable.
> - Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev