Hi Levente --

Thank you for the details. Let me emphasize one of the issues you raised with a quote:

> But such change would break code that relies on the atomicity (actually the lack of suspension points) of those selectors.

That's a tricky one. :-)

Best,
Marcel
Am 21.11.2021 10:59:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
Hi Christoph,

On Sat, 20 Nov 2021, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Hi all!
>
> I am working on a new super exciting simulation project that makes extensive uses of transparent proxy objects via ProtoObject and dynamic forwarding (#doesNotUnderstand:). Usually, my current experiments with dynamic
> forwarding work very well through the entire system, but I identified two kinds of situations in which proxies are not handled transparently:
>
> 1. Parameters that are passed to the VM for a primitive - e.g., #(1) at: (MyFancyProxy on: 1) will not work because most VM primitives expect value objects and do not honor dynamic forwarding. That's not ideal, but I can deal
> with it, because in my situation proxying immediate objects does not make great sense anyway. (Alternatively, I could also adjust the fallback implementation in Object >> #at: to "unpack" the proxy.)
>
> 2. Inlined message sends - such as #ifTrue: or #==. While the first one is only sent to value objects (booleans) only and I thus can filter them out easily, the second is a message that can be sent to any object of any class,
> and the fact that one cannot actually override #== or #~~ is pretty much annoying while working with proxies.
> Here is my question: What would be the simplest way to disable inlined message sends for these selectors? I expect to write something like a simple patch to the encoder, followed by a recompilation of all methods in the image
> for my project.

You can disable the generation of the special bytecodes of #== and #~~
with the following snippet:

(ParseNode classPool at: #StdSelectors)
removeKey: #==;
removeKey: #~~.
CurrentReadOnlySourceFiles cacheDuring: [ Compiler recompileAll ].

You can restore it later by evaluating [VariableNode initialize] and
recompling the system.

> And do you have any idea how significantly this would decrease the overall performance of Squeak?

The overall performance difference will probably be insignificant.
The microbenchmark I came up with earlier[1] for the #class selector shows
1.27x, 1.28x slowdown using primitives or send+bytecode, respectively.
But such change would break code that relies on the atomicity (actually
the lack of suspension points) of those selectors.
And, as you noticed, primitives will not play along with you. They will
still expect #== to mean what it does now. E.g. primitive 132 -
#instVarsInclude:, so you would have to disable those as well.


Levente

[1] https://lists.squeakfoundation.org/pipermail/squeak-dev/2018-November/200761.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211122/10e0396b/attachment.html>