[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
|