SmallInetger as methods was not ready yet....now maybe?

On Fri, 3 Dec 2010, stephane ducasse wrote:

On Dec 3, 2010, at 7:02 PM, Andreas Raab 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.

Me too. They were worked well for normal objects. This is good and valuable hook.

But it is easy to fix - just wrap your ints into something else and you're good to go.

It does not work in mariano special need because the idea was to push as far as possible the idea that we do not have to allocate any new objects and avoid any proxy memory allocation cost. So clearly this is may be a too hackish hack. Else a plain simple (but allocating memory proxy works well but we wanted to know what is the lowest boundary).

I have a working package that can swap out CompiledMethods and replace them with SmallIntegers in the MethodDictionaries. When the method is about to be used by the system, the CompiledMethod is automatically swapped back. It uses the existing ObjectsAsMethods implementation, so I say that SmallIntegers can be used like any other object in this regard.

I didn't test it with SqueakVM, but it definitely works with CogVM.


Levente

Cheers,
 - Andreas

 

On Fri, Dec 3, 2010 at 10:15 AM, Andreas Raab <[hidden email]> wrote:

On 12/3/2010 10:07 AM, Igor Stasenko wrote:

On 3 December 2010 19:02, Andreas Raab<[hidden email]>  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.  

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.

Cheers,
 - Andreas

best

Eliot

On 12/3/2010 4:18 PM, Eliot Miranda wrote:

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.

Not at all. The design of objects-as-methods was deliberately done such that one could use a single wrapper for multiple methods. The only thing you need is to map from selector to method being executed. For example:

MethodSwapper>>run: aSelector with: argsArray in: aReceiver
       "Execute the given method"
       method:= methodMap at: aSelector.
       ^aReceiver withArgs: argsArray executeMethod: method

Then you install a single MethodSwapper instance like here:

swapper := MethodSwapper new.
Morph selectorsAndMethodsDo:[:sel :meth| swapper methodMap at: sel put: meth].
Morph selectorsDo:[:sel| Morph addSelector: sel withMethod: swapper].

At this point the only overhead you have is what's in the (single) MethodSwapper instance and even with a most naive implementation (looking up the index by selector) you'd have 8 bytes per method in your image which I suspect is well below 5% of the image size.

And then of course you can start *really* looking at getting the size down. Did you know that Dan once did a very neat hack where he replaced all symbols with integers? Works great and if you do that you not only reclaim the space for the symbols but also don't need a lookup at all :-)

On 12/3/2010 9:12 PM, Igor Stasenko wrote:

don't need a lookup? how?
you still have a method dictionaries, and keys there are not ordered
nor sequential ( yes, you can make selectors in a single class
to be sequential , like 1 , 2 ,3 ,4 , then you don't need to do a
lookup for a single given class, but for the rest of classes which
obviously contain different set of selectors, you won't be able to do
that).

Sorry, "no lookup" referred to the initial comment of wanting somehow to map selectors to some number (which I presumed was an index into some database to load the unloaded compiled method). Of course, method lookup is still required.

Cheers,
 - Andreas