[Vm-dev] Re: SmallInetger as methods was not ready yet....now maybe?

[Mariano Martinez Peck]

On Sat, Dec 4, 2010 at 1:18 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> 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
>>>> intended
>>>> 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.
>
>
Eliot, I saw these changes, but I wonder if there would be more. I said at
the beginning of this thread...for example, the Interpreter has an instVar
called "newMethod". If at a certain moment tht instVar has a SmallInteger,
do you handle the check in all possible uses of newMethod?  (ok, you did it
in markAndTrace hehe)
Because the methodLookUp, methodExecution, etc, are easy to think and
detect. But with the markAndTrace it ONLY happened to me when trying to swap
out 60000 methods and then, the probability to have a SmallInteger in
newMethod was big. Otherwise, I wouldn't notice the bug hahha


> 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.
>
>
Exactly. And since reserch is about future ;) I was thinking that tomorrow,
we could have 64 bits, with more than 1 object encoded in the address: small
floats, characters, points...whatever. And why not a Proxy class (subclass
of ProtoObject) where you can implement your own  dnu/run:with:in ?

I was even going to suggest change all senders of #isIntegerObject:  by a
new method  #hasObjectHeader: oop  (or whatever name)
and we let this prepare for when we have not only SmallInteger but other
stuff.

Cheers

Mariano





>
>
>> 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.
>>
>> Cheers,
>>  - Andreas
>>
>
> best
> Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101206/15e21a7c/attachment-0001.htm