<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi!<br></div><div><br>Just to clarify, we've actually modified the StackInterpreter>>commonAtPut: with a call to our code. We are building the Stack Spur VM on Mac 64bits. <br></div><div><br></div><div>To validate whether our code was executed or not we've added printf entries to the C code produced in gcc3x-interp.c which is how we noticed the difference between regular execution and debug with proceed or over.</div><div><br></div><div>Here's the modified extract of commonAtPut:</div><div><br></div><div><span style="font-family:monospace,monospace">!StackInterpreter methodsFor: 'indexing primitive support' stamp: 'ALF & MDS 4/7/2019 18:57'!<br></span></div><div><span style="font-family:monospace,monospace">commonAtPut: stringy<br>    "This code is called if the receiver responds primitively to at:Put:.<br>     N.B. this does *not* use the at cache, instead inlining stObject:at:put:.<br>     Using the at cache here would require that callers set messageSelector<br>     and lkupClass and that is onerous and error-prone, and in any case,<br>     inlining produces much better performance than using the at cache here."<br>    | value index rcvr |<br>    <inline: true> "to get it inlined in primitiveAtPut and primitiveStringAtPut"<br>    self initPrimCall.<br>    <span style="background-color:rgb(255,255,0)">self keepCollectionTypeInformation.</span><br>    rcvr := self stackValue: 2.<br>    index := self stackValue: 1.<br>    value := self stackTop.</span></div><div><span style="font-family:monospace,monospace">    ...<br></span></div><div><br><span style="font-family:monospace,monospace"></span></div><div>And here's an extract of our code highlighting how we attempt to get the current MethodContext.<br></div></div><div dir="ltr"><br></div><div dir="ltr"><span style="font-family:monospace,monospace">!StackInterpreter methodsFor: 'dynamic type information' stamp: 'ALF MTQP 4/21/2019 15:46'!<br>keepCollectionTypeInformation<br>    <inline: true><br>    | senderContext receiverObject isLiveTypingCollectionObject contentTypesArray isSenderContextMethodContext collectionsContentType keepSearchingCollectionSender loopbackIndex maxLoopbackIndex|<br><br>    loopbackIndex := 0.<br>    maxLoopbackIndex := 4.<br>    keepSearchingCollectionSender := true.<br>    <span style="background-color:rgb(255,255,0)">senderContext := self ensureFrameIsMarried: framePointer SP: stackPointer.</span><br>    [keepSearchingCollectionSender and: [loopbackIndex < maxLoopbackIndex]] whileTrue: [<br>        senderContext = objectMemory nilObject ifFalse: [<br>            isSenderContextMethodContext := (objectMemory is: senderContext instanceOf: (objectMemory splObj: ClassMethodContext) compactClassIndex: ClassMethodContextCompactIndex)-0.<br>            isSenderContextMethodContext ifTrue: [<br>                receiverObject :=  objectMemory fetchPointer: ReceiverIndex ofObject: senderContext.<br>                receiverObject = objectMemory nilObject ifFalse: [<br>                    isLiveTypingCollectionObject := (objectMemory is: receiverObject instanceOf: (objectMemory splObj: ClassLiveTypingCollection) compactClassIndex: 0)-0. <br>                    isLiveTypingCollectionObject ifTrue: [ ...<br></span></div><div dir="ltr"><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">We are using a custom implementation of OrderedCollection, LiveTypingCollection just to limit the code exposure and have made it a known class to the VM for that reason.</font><br></span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">Is there anything we are missing around the at:put: primitive execution and the commonAtPut: implementation it triggers? Is there another way to obtain the current MethodContext?</font></span></div><div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif"><br></font></span></div><div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">Thanks</font><br></span></div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 9:00 AM <<a href="mailto:vm-dev-request@lists.squeakfoundation.org">vm-dev-request@lists.squeakfoundation.org</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">Send Vm-dev mailing list submissions to<br>
        <a href="mailto:vm-dev@lists.squeakfoundation.org" target="_blank">vm-dev@lists.squeakfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.squeakfoundation.org/mailman/listinfo/vm-dev" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/vm-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:vm-dev-request@lists.squeakfoundation.org" target="_blank">vm-dev-request@lists.squeakfoundation.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:vm-dev-owner@lists.squeakfoundation.org" target="_blank">vm-dev-owner@lists.squeakfoundation.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Vm-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Intercepting at:put: problems (Ana Laura Felisatti)<br>
   2. Re: Intercepting at:put: problems (tim Rowledge)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sun, 28 Apr 2019 15:04:13 -0300<br>
From: Ana Laura Felisatti <<a href="mailto:anafelisatti@gmail.com" target="_blank">anafelisatti@gmail.com</a>><br>
To: <a href="mailto:vm-dev@lists.squeakfoundation.org" target="_blank">vm-dev@lists.squeakfoundation.org</a><br>
Subject: [Vm-dev] Intercepting at:put: problems<br>
Message-ID:<br>
        <CACxgkY=<a href="mailto:iy%2BDqqaOUjCTEQHhexnjyUfrPRwHukNLXT_48y_ZZaw@mail.gmail.com" target="_blank">iy+DqqaOUjCTEQHhexnjyUfrPRwHukNLXT_48y_ZZaw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi!<br>
<br>
We're working with Hernan Wilkinson on the Live Typing VM implementation<br>
and have recently found a very strange behaviour. We are trying to capture<br>
the type of objects stored within an OrderedCollection by intercepting the<br>
at:put: method of Object, since that's what ends up being executed<br>
internally by the OrderedCollection using an internal Array. To identify<br>
whether the at:put: is being executed from that OrderCollection context we<br>
inspect the MethodContext nesting.<br>
<br>
So far we have intercepted the StackInterpreter commonAtPut: to execute our<br>
logic, which attempts to retrieve the current MethodContext, analyse up to<br>
4 levels up looking for an OrderedCollection receiver and in that case<br>
store the type information.<br>
<br>
The problem is that our code never executes on a regular execution but does<br>
while debugging. In fact, it works as expected when we simply hit "Proceed"<br>
but fails when we hit "Over" instead, which is quite unexpected.<br>
<br>
We would like to know if there's anything we might be missing here about<br>
the execution of primitives like at:put: or acquiring the current<br>
MethodContext from the VM side.<br>
<br>
Thanks!<br>
-- <br>
A. Felisatti<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190428/47ad902b/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190428/47ad902b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 28 Apr 2019 11:20:19 -0700<br>
From: tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>><br>
To: Squeak Virtual Machine Development Discussion<br>
        <<a href="mailto:vm-dev@lists.squeakfoundation.org" target="_blank">vm-dev@lists.squeakfoundation.org</a>><br>
Subject: Re: [Vm-dev] Intercepting at:put: problems<br>
Message-ID: <<a href="mailto:C0ACE491-94E5-40BA-96A6-E092255F7EBB@rowledge.org" target="_blank">C0ACE491-94E5-40BA-96A6-E092255F7EBB@rowledge.org</a>><br>
Content-Type: text/plain;       charset=us-ascii<br>
<br>
<br>
<br>
> On 2019-04-28, at 11:04 AM, Ana Laura Felisatti <<a href="mailto:anafelisatti@gmail.com" target="_blank">anafelisatti@gmail.com</a>> wrote:<br>
> <br>
> So far we have intercepted the StackInterpreter commonAtPut: to execute our logic, which attempts to retrieve the current MethodContext, analyse up to 4 levels up looking for an OrderedCollection receiver and in that case store the type information.<br>
> <br>
> The problem is that our code never executes on a regular execution but does while debugging. In fact, it works as expected when we simply hit "Proceed" but fails when we hit "Over" instead, which is quite unexpected. <br>
> <br>
> We would like to know if there's anything we might be missing here about the execution of primitives like at:put: or acquiring the current MethodContext from the VM side.<br>
<br>
It's possible that the commonAtPut() routine has been inlined (looks that way in an ancient copy of interp.c I have lying around) and so if you are trapping in a debugger on the actual routine start then it would be unlikely to hit. If you've modified the commonAtPut() code, then this is unlikely to be a good explanation. <br>
<br>
How exactly have you generated the VM? That might tell us something useful.<br>
<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
Strange OpCodes: IO: Illogical Or<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Vm-dev mailing list<br>
<a href="mailto:Vm-dev@lists.squeakfoundation.org" target="_blank">Vm-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/vm-dev" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/vm-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Vm-dev Digest, Vol 154, Issue 33<br>
***************************************<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">A. Felisatti</div></div></div></div></div></div>