<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Levente --<div><br></div><div>Thank you for the details. Let me emphasize one of the issues you raised with a quote:</div><div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">But such change would break code that relies on the atomicity (actually </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">the lack of suspension points) of those selectors.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">That's a tricky one. :-)</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 21.11.2021 10:59:39 schrieb Levente Uzonyi <leves@caesar.elte.hu>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Christoph,<br><br>On Sat, 20 Nov 2021, christoph.thiede@student.hpi.uni-potsdam.de wrote:<br><br>> Hi all!<br>> <br>> 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<br>> forwarding work very well through the entire system, but I identified two kinds of situations in which proxies are not handled transparently:<br>> <br>> 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<br>> 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.)<br>> <br>> 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,<br>> and the fact that one cannot actually override #== or #~~ is pretty much annoying while working with proxies.<br>> 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<br>> for my project.<br><br>You can disable the generation of the special bytecodes of #== and #~~ <br>with the following snippet:<br><br>(ParseNode classPool at: #StdSelectors)<br>    removeKey: #==;<br>       removeKey: #~~.<br>CurrentReadOnlySourceFiles cacheDuring: [ Compiler recompileAll ].<br><br>You can restore it later by evaluating [VariableNode initialize] and <br>recompling the system.<br><br>> And do you have any idea how significantly this would decrease the overall performance of Squeak?<br><br>The overall performance difference will probably be insignificant.<br>The microbenchmark I came up with earlier[1] for the #class selector shows <br>1.27x, 1.28x slowdown using primitives or send+bytecode, respectively.<br>But such change would break code that relies on the atomicity (actually <br>the lack of suspension points) of those selectors.<br>And, as you noticed, primitives will not play along with you. They will <br>still expect #== to mean what it does now. E.g. primitive 132 - <br>#instVarsInclude:, so you would have to disable those as well.<br><br><br>Levente<br><br>[1] https://lists.squeakfoundation.org/pipermail/squeak-dev/2018-November/200761.html<br><br></div></blockquote></div>