[Vm-dev] Finally Time to Make Good on "Everything is a message send"?

Levente Uzonyi leves at caesar.elte.hu
Mon Sep 18 17:22:35 UTC 2017

On Sun, 17 Sep 2017, Sean P. DeNigris wrote:

> On the "Squeak Beginners" ML, a new Smalltalker wrote:
>> I don't understand why Smalltalk doesn't allow me to have an or:
>> method that takes a block argument (except on Boolean).
> The answer apparently was that the compiler replaces the code with an
> optimization that is usually what one wants, and the actual message never
> gets sent:
>>    Ralph Johnson wrote
>>    Yes, when the compiler sees   exp or: [ ... ] then it assumes that
>> "exp" is
>>   a boolean-valued expression and generates code that fails if it isn't.
> I remember the pain of tripping over these little "everything is a message
> send to an object*" sins as a new Smalltalker. I wonder now, with the
> incredible speed of Cog, Spur, Sista, etc., if these devil's bargains from
> prior decades are still necessary. It would be psychologically satisfying
> (and nice for newbies) to remove the asterisk from the principle above.
> p.s. IIRC e.g. Opal has flags to modify this behavior, but could the actual
> messages be sent by default, and the flag be set to inline when that
> performance boost is actually required?

You can turn off all those optimizations in your image except for 
potentially infinite loops.

The performance drop will be larger than you may think, because Cog has 
its own native implementation for most if not all those methods. So it'll 
skip both primitives and special bytecodes when possible and inline them 
into the jitted code (This can result in nasty debug situations when the 
jitter code's behavior differs from what the image side code suggests).

Also, most of those methods are not newbie-safe. Changing any of them will 
probably freeze your image.

Finally, these changes can only be done on the image side, so this 
question probably belongs to another list.


> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Squeak-VM-f104410.html

More information about the Vm-dev mailing list