<div dir="ltr">Hi Nicolai,<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 9:39 AM, Nicolai Hess <span dir="ltr">&lt;<a href="mailto:nicolaihess@web.de" target="_blank">nicolaihess@web.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div><div>Hi Eliot,<br><br></div>I am pretty sure this is not a vm issue :)<br></div><div><br>The mustBeBooleanInMagic: creates a method on the fly and executes it with the <br>
</div><div>a context as argument.<br>
</div><div>The &quot;ThisContext&quot; is not the &quot;thisContext&quot;, but the argument of the generated method.<br><br></div><div>This is the bytecode of the generated method:<br><br>17 &lt;00&gt; pushRcvr: 0<br>18 &lt;8F 00 00 02&gt; closureNumCopied: 0 numArgs: 0 bytes 22 to 23<br>

22     &lt;76&gt; pushConstant: 1<br>23     &lt;7D&gt; blockReturn<br>24 &lt;8F 00 00 02&gt; closureNumCopied: 0 numArgs: 0 bytes 28 to 29<br>28     &lt;75&gt; pushConstant: 0<br>29     &lt;7D&gt; blockReturn<br>30 &lt;F0&gt; send: ifTrue:ifFalse:<br>

31 &lt;7C&gt; returnTop<br><br></div><div>The original method is<br><br>foo<br>    ^ notABool1 ifTrue:[1] ifFalse:[0]<br><br></div><div>The generated method compiles this part<br>notABool1 ifTrue:[1] ifFalse:[0]<br><br></div>

<div>to bytecode without the jumpFalse optimization. <br>The problem is that the receiver for the ifTrue:ifFalse send is accessed through<br></div><div>pushRcvr:0, whereas the thisContext is not the context of the original method anymore.<br>
</div></div></blockquote><div><br></div><div>Ah, now I know what&#39;s going on.  Thanks.  I like this experiment very much.</div><div><br></div><div>How do you extract the blocks from the method?  Do you decompile or simply recompile from source or...?</div>
<div><br></div><div>Have (any of) you looked at implementing the mustBeBooleanMagic by interpreting the bytecodes that already exist in the method via some specialized interpreter instead of compiling a method on the fly?</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Nicolai</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

2014-08-10 17:34 GMT+02:00 Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

 <br><div dir="ltr">Hi Nicolai,<div><br></div><div>    please try and remember to invlude vm-dev when you see a VM issue...<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 7:34 AM, Nicolai Hess <span dir="ltr">&lt;<a href="mailto:nicolaihess@web.de" target="_blank">nicolaihess@web.de</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>There is a certain risk, that the mustBeBooleanMagicIn method rewrite can crash the<br>


vm<br></div><a href="https://pharo.fogbugz.com/default.asp?13805" target="_blank">Issue 13805</a></div></div></div></div></blockquote><div><br></div><div>Since you&#39;re using the Opal compiler ca you add the description of the bytecode (aCompiledMethod symbolic) to the issue?  I&#39;ll try and take a look soon but want to be sure I&#39;m debugging the relevant code.</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>The receiver of the rewritten method is the &quot;nonboolean&quot; value receiving the<br>


</div>
ifTrue:ifFalse: message. But the rewritten method can include <br>instvar accessor and self sends of the original method.<br><br></div>We can include more rewrite rules in mustBeBooleanMagicIn like<br></div>  &quot;rewrite instvar accessing&quot;<br>



<div>    context receiver class instVarNamesAndOffsetsDo: [ :n :o | <br>        RBParseTreeRewriter new <br>        replace: n with: (&#39;ThisContext receiver instVarAt: &#39;, o asString);<br>        executeTree: methodNode.<br>



        ].<br></div><div>&quot;rewrite self sends&quot;<br></div><div>    RBParseTreeRewriter new <br>        replace: &#39;self&#39; with: &#39;ThisContext receiver&#39;;<br>        executeTree: methodNode.<br><br></div>



<div>But I don&#39;t know if this works for all possible situations. Or if there are<br>better ways to do the rewriting.</div></div></blockquote><div><br></div><div>Remember the mirror methods:</div><div>    thisContext object: o instVarAt:</div>


<div>which doesn&#39;t send to o, reaching directly into it.</div><div><br></div><div>But what&#39;s the point of replacing &quot;self&quot; with &quot;thisContext receiver&quot;?  The latter is potentially an extremely slow way of doing the former.  The former won&#39;t create a context object in a method activation that doesn&#39;t need one (doesn&#39;t include a block), whereas the latter always will.  But they will always yield the same result.</div>


</div>-- <br>curious,<div>Eliot</div></div></div></div></blockquote></div></div></blockquote></div>-- <br>best,<div>Eliot</div>
</div></div>