Hi!

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.

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.

Here's the modified extract of commonAtPut:

!StackInterpreter methodsFor: 'indexing primitive support' stamp: 'ALF & MDS 4/7/2019 18:57'!
commonAtPut: stringy
    "This code is called if the receiver responds primitively to at:Put:.
     N.B. this does *not* use the at cache, instead inlining stObject:at:put:.
     Using the at cache here would require that callers set messageSelector
     and lkupClass and that is onerous and error-prone, and in any case,
     inlining produces much better performance than using the at cache here."
    | value index rcvr |
    <inline: true> "to get it inlined in primitiveAtPut and primitiveStringAtPut"
    self initPrimCall.
    self keepCollectionTypeInformation.
    rcvr := self stackValue: 2.
    index := self stackValue: 1.
    value := self stackTop.
    ...

And here's an extract of our code highlighting how we attempt to get the current MethodContext.

!StackInterpreter methodsFor: 'dynamic type information' stamp: 'ALF MTQP 4/21/2019 15:46'!
keepCollectionTypeInformation
    <inline: true>
    | senderContext receiverObject isLiveTypingCollectionObject contentTypesArray isSenderContextMethodContext collectionsContentType keepSearchingCollectionSender loopbackIndex maxLoopbackIndex|

    loopbackIndex := 0.
    maxLoopbackIndex := 4.
    keepSearchingCollectionSender := true.
    senderContext := self ensureFrameIsMarried: framePointer SP: stackPointer.
    [keepSearchingCollectionSender and: [loopbackIndex < maxLoopbackIndex]] whileTrue: [
        senderContext = objectMemory nilObject ifFalse: [
            isSenderContextMethodContext := (objectMemory is: senderContext instanceOf: (objectMemory splObj: ClassMethodContext) compactClassIndex: ClassMethodContextCompactIndex)-0.
            isSenderContextMethodContext ifTrue: [
                receiverObject :=  objectMemory fetchPointer: ReceiverIndex ofObject: senderContext.
                receiverObject = objectMemory nilObject ifFalse: [
                    isLiveTypingCollectionObject := (objectMemory is: receiverObject instanceOf: (objectMemory splObj: ClassLiveTypingCollection) compactClassIndex: 0)-0.
                    isLiveTypingCollectionObject ifTrue: [ ...

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.

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?

Thanks

On Mon, Apr 29, 2019 at 9:00 AM <vm-dev-request@lists.squeakfoundation.org> wrote:
Send Vm-dev mailing list submissions to
        vm-dev@lists.squeakfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
or, via email, send a message with subject or body 'help' to
        vm-dev-request@lists.squeakfoundation.org

You can reach the person managing the list at
        vm-dev-owner@lists.squeakfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Vm-dev digest..."


Today's Topics:

   1. Intercepting at:put: problems (Ana Laura Felisatti)
   2. Re: Intercepting at:put: problems (tim Rowledge)


----------------------------------------------------------------------

Message: 1
Date: Sun, 28 Apr 2019 15:04:13 -0300
From: Ana Laura Felisatti <anafelisatti@gmail.com>
To: vm-dev@lists.squeakfoundation.org
Subject: [Vm-dev] Intercepting at:put: problems
Message-ID:
        <CACxgkY=iy+DqqaOUjCTEQHhexnjyUfrPRwHukNLXT_48y_ZZaw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi!

We're working with Hernan Wilkinson on the Live Typing VM implementation
and have recently found a very strange behaviour. We are trying to capture
the type of objects stored within an OrderedCollection by intercepting the
at:put: method of Object, since that's what ends up being executed
internally by the OrderedCollection using an internal Array. To identify
whether the at:put: is being executed from that OrderCollection context we
inspect the MethodContext nesting.

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.

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.

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.

Thanks!
--
A. Felisatti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190428/47ad902b/attachment-0001.html>

------------------------------

Message: 2
Date: Sun, 28 Apr 2019 11:20:19 -0700
From: tim Rowledge <tim@rowledge.org>
To: Squeak Virtual Machine Development Discussion
        <vm-dev@lists.squeakfoundation.org>
Subject: Re: [Vm-dev] Intercepting at:put: problems
Message-ID: <C0ACE491-94E5-40BA-96A6-E092255F7EBB@rowledge.org>
Content-Type: text/plain;       charset=us-ascii



> On 2019-04-28, at 11:04 AM, Ana Laura Felisatti <anafelisatti@gmail.com> wrote:
>
> 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.
>
> 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.
>
> 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.

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.

How exactly have you generated the VM? That might tell us something useful.


tim
--
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: IO: Illogical Or




------------------------------

Subject: Digest Footer

_______________________________________________
Vm-dev mailing list
Vm-dev@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/vm-dev


------------------------------

End of Vm-dev Digest, Vol 154, Issue 33
***************************************


--
A. Felisatti