On Sat, 24 Nov 2018, Chris Muller wrote:

>>> Chris Muller uploaded a new version of Kernel to project The Inbox:
>> > http://source.squeak.org/inbox/Kernel-cmm.1198.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: Kernel-cmm.1198
>> > Author: cmm
>> > Time: 23 November 2018, 11:12:47.414703 pm
>> > UUID: fe228ca8-2ec7-4432-b3d9-76da98be4475
>> > Ancestors: Kernel-eem.1197
>> >
>> > - Suggestion that #basicClass should be inlined while #class should be a message send, so that Proxy's can be supported.
>>
>> It won't work while the special bytecode for #class is compiled. And even
>> after that, you have to recompile all senders of #class to make it use
>> the primitive and the new method instead of optimizing it away.
>
> Right.  Assuming we can achieve consensus with Eliot, and the next
> Squeak will have a new VM, then that would be called from an MC post
> script.

I don't see what kind of VM changes are necessary here. Care to elaborate?

>
> But what do you mean make all senders of #class use the primitive?

Currently, when you compile a method containing a send of #class, the 
compiler will generate a special bytecode for it (199).
When the interpreter/jit sees this bytecode, it will not perform a send 
nor a primitive; it'll just look up the class of the receiver and place it 
on top of the stack.
You can see this in action by removing the sole implementor of #class from 
your image without any effects. That method is only there for 
consistency, it is never executed.

So, while the bytecode is in use, it doesn't matter what you do with the 
#class method, because it will never be sent.

> Just as you suggested the use of #ensureNonProxiedReceiver from the
> other thread, the intention here is that #basicClass would better
> document those performance-critical places, but leaving the majority
> (of non-critical ones) sending #class, so it can be overridable.

See above.

>
> Do you think the system would be noticably slower if all the sends to
> #class became a message send?  I'm skeptical that it would, but I have

Yes, the bytecode is way quicker than the primitive or a primitive + a 
send which is exactly what you suggested.
Also, removing the bytecode will make #class lose its atomicity. Any code 
that relies on that behavior will silently break. This pretty much applies 
to all special selectors (See SmalltalkImage >> #specialSelectors).

> no idea.  I am surprised to see we have so many senders of #class in
> trunk, but I have a feeling most rarely ever called.

I doubt that. People don't sprinkle #class sends for no reason, do they?

>
> Removing those byteCodes from my CompiledMethods is above my knowledge
> level, but if you could help me come up with a script, I'd be
> interested in testing and playing around to learn more.

VariableNode has a class variable named StdSelectors. It contains the 
selectors for which custom bytecodes are generated. Removing #class from 
there should be enough.

>
>> > - If so, then #xxxClass can be banished.
>> > - With #xxxClass banished, the Squeak code that called it can be written normally, simply as "class".
>>
>> That won't work either for the same reason. And we do not want to remove
>> the bytecode, do we?
>
> Not remove it, redirect it to #basicClass.

Right, but while the bytecode is in effect, you just can't redirect 
it.

Levente

>
> This is a reasonable and familiar pattern, right?  It provides users
> full control and WYSIWIG between source and bytecodes due to a crystal
> clear selector name.  No magic.
>
> - Chris
>
> - Chris