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:
- Intercepting at:put: problems (Ana Laura Felisatti)
- 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