<div dir="ltr"><div>Hi Eliot</div><div><br></div><div dir="ltr">чт, 28 мар. 2019 г. в 23:29, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr">Hi Denis,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 28, 2019 at 2:36 PM Denis Kudriashov <<a href="mailto:dionisiydk@gmail.com" target="_blank">dionisiydk@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr">Hi Nicolas.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 28 мар. 2019 г. в 19:44, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="auto">Hi Denis,<div dir="auto">Special bytecodes don't have to be changed: just don't use them and replace by regular sends at bytecode generation (with a special compiler, or some IR translater). </div></div></blockquote><div><br></div><div>Sure, bytecode transformation will work. But it would be quite tricky to apply in live execution context. It would require fixing context stack to take into account updated method bytecode.</div><div>Notice that I don't search for global setting to recompile all methods in image. I want this logic only for concrete method/block activation. In my scenario block is serialized and transferred together with current context. So on remote side I need to do something with materialized objects to maintain normal block semantics.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">All can be done at image side then. Or did I miss something?</div></div></blockquote><div><br></div><div>I think my examples shows a security hole in VM execution logic which allows to violate memory bounds from the image side.</div></div></div></blockquote><div><br></div><div>It is no different than using an inst var access bytecode on an object which doesn't have enough net vars.  It is not a security hole, as much as it is something the system must use correctly to avoid crashes.  The same can be done by e.g.</div><div><br></div><div>    thisContext swapSender: Point basicNew</div><div><br></div><div>There are many such "security holes".  And if you want the VM to plug them all then the VM will become very much slower.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> I did not got segfault but I would not be surprized if it would happens in some complex real live scenarios. Maybe it looks like a specially invented case but I think it is quite easy to get when using or developing low level serialization library - as soon as you by mistake or intentionally serialize context objects with some substitution logic.</div><div>And considering that this hole needs to be closed it would be good opportunity to have another hook in execution engine which can be used like in my remote scenario. So back to my proposal in first mail.</div></div></div></blockquote><div><br></div><div>If you want to solve this, then build a transformation for the block method when you remote a block.  As others have suggested (Levente) you can transform the bytecodes into normal sends (my blog post on the entire scheme starts with implementing it using at: and at:put: before the special bytecodes are added).  But making a change to all blocks breaks much of the Sista adaptive optimizer.  We have to have the freedom to access indirect temp vectors via special case bytecodes if we are to be able to aggressively optimize code.  If indirect temp vectors are to be treated as general purpose objects, then we are prevented from making many significant optimizations.</div></div></div></blockquote><div><br></div><div>Ok. I expected such answers :) but ask for the chance that some cheap trick is possible. Like my readOnly example. It shows that there is at least writebarrier check during this operation. If it would signal an error it could be used to do the job. </div><div>Method transformation would be quite complex to use because It needs to be applied dynamically to live context, and it requires stack modifications on the fly. Just compiling method in advance is not appropriate for my goal. I don't want to change compiler globally or force user to do it for concrete method/class. It would be not transparent solution. <br></div><div><br></div><div>Anyway thanks all for answers.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>So, as the doctor said, "don't do that".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 28 mars 2019 à 20:05, Denis Kudriashov <<a href="mailto:dionisiydk@gmail.com" target="_blank">dionisiydk@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi.<div><br></div><div>I found interesting case where tempVectors can be used in remote scenarios. The store into remote temp can be really remote (not just about outer context). </div><div>I played with following example:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>| temp | </div><div>temp := 10.</div><div>remote evaluate: [temp := temp + 1].</div><div>temp.</div></blockquote><div><br></div><div>For the moment forget about remote thing and look into it as a normal local case:</div><div>temp var here is managed indirectly through tempVector. You can see it using expression after first assignment:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>thisContext at: 1 "=>#(10)"</div></blockquote></div><div><br></div><div>So the value in fact is stored in the array instance and read from it. </div><div>But because of optimization it happens out of the array control. No #at: and #at:put: messages are sent during this code. VM magically changes the state of this array (there are special bytecodes for this).</div><div><br></div><div>Now my remote use case. Imagine that vm actually sends #at: and #at:put: messages to tempVector. Then remoting engine can transfer temp vector (as part of context) as a proxy. So on remote side the block [temp := temp + 1] will actually ask the sender (client) for the value and for the storage. So all block semantics will be supported. Temp in remote outer context will be modified. I think it would be super cool if such transparency would be possible.</div><div><br></div><div>I played with this example using Seamless in Pharo. It already works in the way I described but due to VM optimization it does not provide expected behavior. And worse than that it actually corrupts transferred proxy because in place of array the proxy instance is materialized. </div><div><br></div><div>This leads us to the issue with safety of tempVector operations. Following example shows how we can affect the state of tempVector using reflection:<br></div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div>| temp | </div></div></div><div><div><div>temp := 10.</div></div></div><div><div><div>(thisContext at: 1) at: 1 put: 50.</div></div></div><div><div><div>[temp := temp + 1] value.</div></div></div><div><div><div>temp. "==>51"</div></div></div><div><br></div></blockquote><div>It is cool that we can do it. But there is no any safety check in the VM level over tempVector object: </div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div>| temp | </div></div></div><div><div>temp := 10.</div></div><div><div>thisContext at: 1 put: Object new.</div></div><div><div>[temp := temp + 1] value.</div></div><div><div>temp.</div></div></blockquote><div dir="ltr"><div><br></div><div>It breaks with DNU: #+ is sent to nil. Temp became nil.</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><br class="gmail-m_5992832458498731651gmail-m_-3905756510476562214gmail-m_-6725007066293236111m_6661563869218237041gmail-Apple-interchange-newline">| temp | </div></div></div><div><div>temp := 10.</div></div><div><div>thisContext at: 1 put: #() copy.</div></div><div><div>[temp := temp + 1] value.</div></div><div><div>temp.</div></div></blockquote><div dir="ltr"><div><br></div><div>Sometimes it breaks with same error. Sometimes it returns random number. </div><div>I guess in these cases VM breaks memory boundary of tempVector.</div><div><br></div><div>And two exotic cases: </div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><br class="gmail-m_5992832458498731651gmail-m_-3905756510476562214gmail-m_-6725007066293236111m_6661563869218237041gmail-Apple-interchange-newline">| temp | </div></div></div><div><div>temp := 10.</div></div><div><div>(thisContext at: 1) beReadOnlyObject.</div></div><div><div>[temp := temp + 1] value.</div></div><div><div>temp.</div></div></blockquote><div dir="ltr"><div><br></div><div>It silently return 11. It does not break read only protection. But no error is signalled.</div><br class="gmail-m_5992832458498731651gmail-m_-3905756510476562214gmail-m_-6725007066293236111m_6661563869218237041gmail-Apple-interchange-newline"></div></div></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div><div>| temp | </div></div></div></div></div><div><div><div><div><div>temp := 10.</div></div></div></div></div><div><div><div><div><div>(thisContext at: 1) become: #() copy.</div></div></div></div></div><div><div><div><div><div>[temp := temp + 1] value.</div></div></div></div></div><div><div><div><div><div>temp.</div></div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div><br></div><div>It returns #().  (In Pharo  #() + 1 = #()  ).</div><div>I use become to check how forwarding is working in that case. (it works fine when array has correct size)</div><div><br></div><div dir="ltr"><div>How we can improve this behavior? How it would effect performance?</div><div>My proposal is to send real messages to tempVector when it is not an array instance. Then image will decide what to do.</div><div><br></div><div>Best regards,</div><div>Denis</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_5992832458498731651gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
</blockquote></div></div>