[squeak-dev] sends of #class and #== considered harmful, may we please stop?

Marcus Denker marcus.denker at inria.fr
Wed Nov 28 15:45:45 UTC 2018



> On 23 Nov 2018, at 19:59, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Hi Chris,
> 
>> On Nov 22, 2018, at 9:20 AM, Chris Muller <asqueaker at gmail.com> wrote:
>> 
>> Hi guys,
>> 
>> Something I've been wanting to ask the community for years, but never
>> had the gumption, was about changing how we write our #= and #hash
>> methods, but now that we're combing through them anyway, I must!
>> 
>> Basically, it comes down to Proxy's.  I want them to work better in
>> Squeak.  But every time we put another send to #class or #== in an
>> implementation of #=, since those methods are inlined, they're too
>> brittle to work with Proxy's.  This causes hard-to-trackdown bugs in
>> applications and mini-messes to deal with them since the app is forced
>> to change its code to become "aware" of potential Proxy'iness of an
>> object before comparing it with #=.
> 
> The disease is the inclining of #class and #==, not the use of these in comparison methods.  In the VisualWorks vm I implemented a command-line/image header switch that enabled/disabled this inlining.  It is easy to implement the same thing on Cog.
> 
> If we did, then these methods would not be inlined if the flag is enabled, on a per-image basis.  
> 
Another idea might be to have a “slow bit” at a per object level: if that is set, some reifications would be done that normally are not done.
I read about this being done in JavaScript, at least at some point they made proxies practical with that approach.

> An alternative is Marcus Denker’s Opal compiler for Pharo which compiles #class and #== to normal sends, avoiding the inlined special selector bytecodes for these sends.  That’s arguably an even better solution, because it retains the ability to inline.  Although the mirror methods objectClass: and object:eqeq: can be used, with more overhead.
> 

Do we really still need the speed we get from the special byte code? I am not sure if I remember correctly, but I think for #class this was already 2004 that Andreas discussed that in Bern when he visited, we even benchmarks and decided that it would be ok to not have a special #class bytecode without too much bad performance impact.

And it is late-binding something that is not late bound now. I always liked that as a “guiding direction”...

	Marcus



More information about the Squeak-dev mailing list