Please confirm/deny that MethodContext sender is nilled by the Interpreter.

Previous Topic Next Topic
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Please confirm/deny that MethodContext sender is nilled by the Interpreter.


I while ago, while studying Eliot's factorial copy example I made the mistake of assuming that since the sender of the MethodContext was the UndefinedObject (which is the Nil object) that that was why the sender was nil.

Eliot corrected me, writing:

Assuming you're not joking, that's not what it means at all. 
The sender points to the sender context *until* it is returned from. 
We're inspecting a block, which got created in the Doit context for the expression [:n| ....]. 
And that DoIt context is the home context of the [:n|...] block. 
The DoIt context returned its result (the [:n|...] block) to whatever the sender context was. 
But when the DoIt context returned that result the DoIt context's sender was nilled, to indicate that it had been returned from
So by the time the [:n|...] block was inspected its home context's sender was nil.

I spent some time trying to figure out exactly where that happens and I believe I have followed it to "system space" where I would like to leave things for now. If I am in fact correct.

Following the code of Eliot's factorial copy example, The DoIt travels through user space, to the Compiler's

Compiler >> evaluate: textOrStream in: aContext to: receiver notifying: aRequestor ifFail: failBlock logged: logFlag

and ends up at <primitive:188> in Object >>withArgs: argArray executeMethod: compiledMethod

{A whole bunch of stuff happens in System Space that I am do not know how to trace yet--but eventually, the return must}

In the BlueBook on page 608, There is a section on Return Bytecodes where bytecode 123 does set the sender nil.

   currentBytecode = 120
      ifTrue: [tself returnValue: receiver
                     to: self sender].
   currentBytecode = 121
      ifTrue: [tself returnValue: TruePointer
                     to: self sender].
   currentBytecode = 122
      ifTrue: [tself returnVatue: FalsePointer
                     to: self sender].
  currentBytecode = 123
      ifTrue: [tself returnValue: NilPointer
                     to: self sender].

Which exists on Squeak's Interpreter and is mapped to instance method

Interpreter >> returnNil.

and finally, Interpreter >> commonReturn

that seems the most possible path to me.

Conversely, any possibility of the sender being nilled in User Space would have to call

Browsing the senders of that method paired with no apparent semaphores in the Compiler method, leads me to conclude it happens in system space.

Does that sound like its in the ballpark? Details are not neccessary as my goal was to just account for every variable we see in a Context.



VM-beginners mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: Please confirm/deny that MethodContext sender is nilled by the Interpreter.

Bert Freudenberg
On 10.01.2014, at 14:31, gettimothy <[hidden email]> wrote:

I spent some time trying to figure out exactly where that happens 
Interpreter >> commonReturn


thisCntx := activeContext.
[thisCntx = localCntx]
["climb up stack to localCntx"
contextOfCaller := objectMemory fetchPointer: SenderIndex ofObject: thisCntx.

"zap exited contexts so any future attempted use will be caught"
objectMemory storePointerUnchecked: SenderIndex ofObject: thisCntx withValue: nilOop.
objectMemory storePointerUnchecked: InstructionPointerIndex ofObject: thisCntx withValue: nilOop.
reclaimableContextCount > 0 ifTrue:
["try to recycle this context"
reclaimableContextCount := reclaimableContextCount - 1.
objectMemory recycleContextIfPossible: thisCntx].
thisCntx := contextOfCaller].

- Bert -

VM-beginners mailing list
[hidden email]

smime.p7s (5K) Download Attachment