<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="auto">Hi Christoph,<div dir="ltr"><br><blockquote type="cite">On Feb 14, 2020, at 9:51 AM, Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de" target="_blank">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">





<div id="gmail-m_-8834739960154282493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>Hi Eliot,</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">Or provide a vm flag which controls whether special selector #class (the bytecode for sending #class) is inlined or not.  This flag can also control #== & #~~.</span></p>
<div><br>
</div>
<div>Could you give me some (code) pointers about this inlining? :-)</div></div></div></blockquote><div><br></div><font face="arial, sans-serif" size="4">This is something I first did in VW 3.0 so that people working with proxies could avoid the inlining of #== & #class.  See primitive 537 in VW. The blue book definition for special selector #class & special selector #== has them inlined.  See pp 618 (640 in the online pdf) through 619 in the blue book, and methods specialSelectorPrimitiveResponse and commonSelectorPrimitiveResponse.  In the VM sources see bytecodePrimClass, bytecodePrimIdentical et al in initializeBytecodeTableForSqueakV3PlusClosures, initializeBytecodeTableForSistaV1 and the implementations in StackInterpreter.</font></div><div dir="auto"><font face="arial, sans-serif" size="4"><br></font></div><div dir="auto"><font face="arial, sans-serif" size="4">The other special selector send bytecodes either apply only to a specific set of classes (e.g. arithmetic is inlined for any combination of SmallInteger and float) or simply function as a space saver (1 byte for the bytecode instead of 1 byte for the send bytecode plus 4 or 8 bytes for the literal selector).  But #class, #== & #~~ are inlined.  They apply to any and all objects.  This is how the system has been defined.  IMO it is a mistake and no longer justified on performance grounds.  But t is the reality on the ground.  And changing it will take some effort.</font></div><div dir="auto"><font face="arial, sans-serif" size="4"><br></font></div><div dir="auto"><div dir="auto"><font face="arial, sans-serif" size="4">self systemNavigation browseAllSelect: [:m| (m selector beginsWith: 'bytecodePrim') and: [(m messages includes: #normalSend) not]] localTo: StackInterpreter</font></div><div dir="auto"><font face="arial, sans-serif" size="4"><br></font></div><div><font face="arial, sans-serif" size="4">(and in the Cogit see implementations of genSpecialSelectorEqualsEquals, genSpecialSelectorClass, genSpecialSelectorNotEqualsEquals).</font></div><div><font face="arial, sans-serif" size="4"><br></font></div><div><font face="arial, sans-serif" size="4">What I propose is adding a flag bit that persists in the image header, queryable/settable via a vmParameterAt: that turns off this inlining, and turns them into true sends.  I think we'll see slow downs in the 5% to 10% range because of the cost of looking up #== (used heavily in ifNotNil: et al) and we can reduce this by e.g. inlining for nil as a receiver and having the bytecode compiler generate pushNil pushFoo send #== for ifNotNil et al.</font></div><div><font face="arial, sans-serif" size="4"><br></font></div><div><font face="arial, sans-serif" size="4">Note that Nicolas did something very similar recently to provide control over mixed mode arithmetic.  He added the primitiveDoMixedArithmetic flag, controlled by flag bit 6 in the VM primitive flags (vm parameter 48).  Something like noInlineCommonSelectors would be controlled by bit 7.</font></div><div><br><blockquote type="cite"><div dir="ltr"><div id="gmail-m_-8834739960154282493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<div><br>
</div>
<div>> <span style="font-size:12pt">There is a good solution to this.  Low-level Inspectors *should not* use instVarAt: et al.  Instead they should access object intervals via “the mirror protocol”, see the methods in Context, #object:instVarAt:[put:] #object:at:[put:]
 #objectClass:</span>
<div><br>
</div>
<div>I like and do agree to your vision for tidying up ProtoObject!</div>
<div>Maybe we could also consider some "MetaDecorator" that inherits from ProtoObject and implements #class, #instVarAt: etc. for arbitrary targets? This might simplify the access to the mirror protocol, and it would be a bit more object-oriented:</div>
<div><br>
</div>
<div>(MetaDecorator on: aMorph) class "--> Morph"</div>
<div><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">(MetaDecorator on: aProxy</span><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">)
 class "--> Proxy"</span><br>
</div>
<div><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">(MetaDecorator
 on: aProxy</span><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">) instVarsInclude: 'target' "--> true"</span><br>
</span></div><div><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"><br></span></span></div></div></div></div></blockquote><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px;color:rgb(0,0,0)">Sounds good.</span><br><blockquote type="cite"><div dir="ltr"><div style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><div>
<div><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"><br>
</span></span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">> </span></span>Hopefully
 I’ve answered your questions and given you pointers.  I’m interested in collaborating to make this a reality in the next major release.<span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<div><br>
</div>
<div>You did. I'm too.</div><div><br></div></span></span></div></div></div></div></blockquote><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px;color:rgb(0,0,0)">Cool. Let's do it :-)  I'm of course busy until next week.  But come Tuesday I should be able to have at it.</span><br><blockquote type="cite"><div dir="ltr"><div style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><div><div><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
</span></span></div>
</div>
<p></p>
<div id="gmail-m_-8834739960154282493Signature">
<div id="gmail-m_-8834739960154282493divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-8834739960154282493divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>><br>
<b>Gesendet:</b> Freitag, 14. Februar 2020 18:27:14<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] [Bug & design issue] Messages understood or not understood by ProtoObject</font>
<div> </div>
</div>
<div>Hi Christoph,
<div dir="ltr"><br>
<blockquote type="cite">On Feb 14, 2020, at 5:18 AM, Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de" target="_blank">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div id="gmail-m_-8834739960154282493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>Hi all! :-)</p>
<p>When we were fiddling around with some proxy implementations today, Marcel and I discovered an interesting set of issues regarding ProtoObjects.</p>
<p>Let's start with a concrete bug:</p>
<p><br>
</p>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<p><b>Code to reproduce <do it>:</b></p>
<p>ProtoObject new class.</p>
<p><br>
</p>
<p><b>Expected behavior:</b></p>
<p>DNU exception, because #class is implemented on Object only.</p>
<p><br>
</p>
<p><b>Actual behavior:</b></p>
<p>Outputs ProtoObject.</p>
<p>Even stranger: If you debug the method instead and simulate the #class send, you get a "simulated message class not understood" error.</p>
<p>If you subclass ProtoObject and override/forward #class, the results will deviate based on whether you are debugging or executing the code.</p>
</blockquote>
<p><br>
</p>
<p><b>Some thoughts:</b></p>
<p><span style="font-size:12pt">There are two options: Either to implement #class on ProtoObject (by </span><span style="font-size:12pt">moving the primitive definition up from Object</span><span style="font-size:12pt">), or to </span><span style="font-size:12pt">remove
 it from the specialObjectsArray so that a send to #class is not compiled differently than a send to any other regular message.</span><br>
</p>
</div>
</div>
</blockquote>
<div><br>
</div>
Or provide a vm flag which controls whether special selector #class (the bytecode for sending #class) is inlined or not.  This flag can also control #== & #~~.<br>
<blockquote type="cite">
<div dir="ltr">
<div id="gmail-m_-8834739960154282493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p></p>
<p><span style="font-size:12pt"><br>
</span></p>
<p>This leads us to the rather general question: <b>What special messages should an instance of ProtoObject understand?</b></p>
</div>
</div>
</blockquote>
<div><br>
</div>
IMO *only* #doesNotUnderstand:
<div><br>
</div>
<div>See below on the mirror protocol</div>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div id="gmail-m_-8834739960154282493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>We don't answer this question completely consistent at the moment: For example, #instVarAt: is implemented on Object, but #instVarsInclude: is implemented on ProtoObject. Again, it is a bit weird that the implementation of #instVarsInclude: calls #class
 which is implemented on Object only. And so it goes on:</p>
<p></p>
<ul style="margin-bottom:0px;margin-top:0px">
<li>#someObject is implemented on Object, but #nextObject is available in ProtoObject.</li><li>#withArgs:executeMethod: is implemented on ProtoObject, whereas #perform:withArguments: is on Object.</li><li>#ifNotNil: is implemented on ProtoObject; however, #ifNotNilDo: is implemented on Object. (btw: does the latter still have any <span>raison d'être?)</span></li><li><span>#flag: exists on ProtoObject, and #yourself exists on Object only. Isn't #yourself rather a syntactical element we would like to behave exactly the same way for every possible message receiver? (btw: Is there a good reason not to speed up #yourself
 via specialObjectsArray)?</span></li><li><span>(I don't claim for completeness)</span></li></ul>
<div><br>
</div>
<div>And just some other problems regarding to ProtoObject (just collecting them here instead of forgetting them forever):</div>
<div>
<ul style="margin-bottom:0px;margin-top:0px">
<li><span>ObjectTracer is broken due to several reasons. Will fix this soon.</span><br>
</li><li><span>Inspectors cannot inspect ProtoObjects correctly (for example: <span>Inspector openOn: (ObjectTracer on: Display)). This is because #instVarAt: is implemented on Object only so this message is forwarded.<br>
Maybe we should replace these critical calls from Inspector by something like #tryPrimitive:173withArgs:? But should we do so in Inspector or rather in a new subclass named ProtoInspector or similar? Hm, then we would need to implement #inspectorClass on ProtoObject,
 which is bad either ... We will keep investigating this issue.</span></span></li></ul>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
There is a good solution to this.  Low-level Inspectors *should not* use instVarAt: et al.  Instead they should access object intervals via “the mirror protocol”, see the methods in Context, #object:instVarAt:[put:] #object:at:[put:] #objectClass:</div>
<div><br>
</div>
<div>You see hacks everywhere (the xxxFoo messages in serialization) because we don’t have a well-defined notion of what is in a proxy.  Having one that is as minimal as possible is IMNERHO the clearest definition possible, and the most minimal is just having
 a #doesNotUnderstand: that prevents recursive does not understand vm exit and displays a stack trace without sending further messages to the proxy (because it uses the mirror primitives).</div>
<div><br>
</div>
<div>Note that the mirror primitives are what the execution machinery in Context use to ensure that bytecodes do what they are expected to do.  An I et car access should *not* send instVarAt: to a proxy; it should access the inst var of the proxy, etc.</div>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div id="gmail-m_-8834739960154282493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<div>
<div><br>
</div>
</div>
<div>However, the crucial question is: What special messages should an instance of ProtoObject understand? On the one hand, the idea of ProtoObjects is to work as total proxies with a maximum amount of forwarding potential, which implies a minimum number of
 methods. On the other hand, certain aspects such as accessing instvars or executing messages are really identity-related. <span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">Looking
 forward to your comments :-)</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
Hopefully I’ve answered your questions and given you pointers.  I’m interested in collaborating to make this a reality in the next major release.</div>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div id="gmail-m_-8834739960154282493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
<p></p>
<p></p>
<p><span></span></p>
<div id="gmail-m_-8834739960154282493Signature">
<div id="gmail-m_-8834739960154282493divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<span></span><br>
</div>
</blockquote>
</div>
</div>


<span></span><br></div></blockquote></div></div></div></div></div></div></div></div>