[Vm-dev] Re: [Pharo-dev] mustBeBooleanMagicIn can crash the vm

Eliot Miranda eliot.miranda at gmail.com
Sun Aug 10 15:34:16 UTC 2014

Hi Nicolai,

    please try and remember to invlude vm-dev when you see a VM issue...

On Sun, Aug 10, 2014 at 7:34 AM, Nicolai Hess <nicolaihess at web.de> wrote:

> There is a certain risk, that the mustBeBooleanMagicIn method rewrite can
> crash the
> vm
> Issue 13805 <https://pharo.fogbugz.com/default.asp?13805>

Since you're using the Opal compiler ca you add the description of the
bytecode (aCompiledMethod symbolic) to the issue?  I'll try and take a look
soon but want to be sure I'm debugging the relevant code.

The receiver of the rewritten method is the "nonboolean" value receiving the
> ifTrue:ifFalse: message. But the rewritten method can include
> instvar accessor and self sends of the original method.
> We can include more rewrite rules in mustBeBooleanMagicIn like
>   "rewrite instvar accessing"
>     context receiver class instVarNamesAndOffsetsDo: [ :n :o |
>         RBParseTreeRewriter new
>         replace: n with: ('ThisContext receiver instVarAt: ', o asString);
>         executeTree: methodNode.
>         ].
> "rewrite self sends"
>     RBParseTreeRewriter new
>         replace: 'self' with: 'ThisContext receiver';
>         executeTree: methodNode.
> But I don't know if this works for all possible situations. Or if there are
> better ways to do the rewriting.

Remember the mirror methods:
    thisContext object: o instVarAt:
which doesn't send to o, reaching directly into it.

But what's the point of replacing "self" with "thisContext receiver"?  The
latter is potentially an extremely slow way of doing the former.  The
former won't create a context object in a method activation that doesn't
need one (doesn't include a block), whereas the latter always will.  But
they will always yield the same result.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140810/174120b8/attachment.htm

More information about the Vm-dev mailing list