The Trunk: Kernel-eem.1086.mcz

Eliot Miranda uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-eem.1086.mcz

==================== Summary ====================

Name: Kernel-eem.1086
Author: eem
Time: 4 April 2017, 5:56:56.293644 pm
UUID: b7a5b8d8-6a97-4193-87b9-f1ca83a6f52d
Ancestors: Kernel-eem.1085

Improve Context's comment and move methods out of the effectively obsolete closure-specific instruction-decoding category.

=============== Diff against Kernel-eem.1085 ===============

Item was changed:
  InstructionStream variableSubclass: #Context
  instanceVariableNames: 'stackp method closureOrNil receiver'
  classVariableNames: 'MaxLengthForASingleDebugLogReport MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep ValueIndex'
  poolDictionaries: ''
  category: 'Kernel-Methods'!
 
+ !Context commentStamp: 'eem 4/4/2017 17:45' prior: 0!
+ My instances hold all the dynamic state associated with the execution of either a method activation resulting from a message send or a block activation resulting from a block evaluation.  In addition to their inherited state, this includes the receiver (self), the closure for a BlockClosure activation (which is nil for a method activation), a CompiledMethod, and space in the variable part of the context for arguments, temporary variables, and intermediate results, and the stack pointer to the top of stack in this variable part.
+
+ Contexts are created automatically (at least conceptually (*)) whenever a message send activates a method, or a block evaluation activates a block.  The current context can always be accessed via the thisContext pseudo-variable.  For example, explore the following:
+ { thisContext. thisContext copy. thisContext method. thisContext pc. thisContext receiver. thisContext stackPtr. thisContext sender }.
+
+ Contexts refer to the context in which they were created via the sender inst var.  An execution stack is made up of of a linked list of contexts, linked through their sender inst var. Returning involves returning back to the sender.  When a context is returned from its sender and pc are nilled, and, if the context is still referred to, the virtual machine guarantees to preserve only the arguments after a return.  A Smalltalk Process is simply a chain of contexts specific to that process.  The debugger is essentially a Process inspector.  Stepping in the debugger is done by sending messages to contexts to get them to execute their bytecodes.  See methods in the instruction decoding protocol.
+
- !Context commentStamp: 'eem 3/30/2017 17:27' prior: 0!
- My instances hold all the dynamic state associated with the execution of either a method activation resulting from a message send or a block activation resulting from a block evaluation.  In addition to their inherited state, this includes the receiver (self), the closure for a BlockClosure activation (which is nil for a method activation), a CompiledMethod, and space in the variable part of the context for arguments and temporary variables.
-
  Contexts, though normal in their variable size, are actually only used in two sizes, small and large, which are determined by the temporary space required by the method being executed.
 
+ Contexts must only be created using the method newForMethod:.  Note that it is impossible to determine the real object size of a Context except by asking for the frameSize of its method.  Any fields above the stack pointer (stackp) are truly invisible -- even (and especially!!) to the garbage collector.  Any store into stackp other than by the primitive method stackp: is potentially fatal.
+
+ (*) efficient virtual machines create contexts lazily on demand, avoiding the overhead of creating them on every message send and of copying receiver and arguments from sender context to caller context.  This optimization is invisible to the Smalltalk system.!
- Contexts must only be created using the method newForMethod:.  Note that it is impossible to determine the real object size of a Context except by asking for the frameSize of its method.  Any fields above the stack pointer (stackp) are truly invisible -- even (and especially!!) to the garbage collector.  Any store into stackp other than by the primitive method stackp: is potentially fatal.!

Item was changed:
+ ----- Method: Context>>blockReturnTop (in category 'instruction decoding') -----
- ----- Method: Context>>blockReturnTop (in category 'instruction decoding (closures)') -----
  blockReturnTop
  "Simulate the interpreter's action when a ReturnTopOfStackToCaller bytecode is
  encountered in the receiver.  This should only happen in a closure activation."
  self assert: closureOrNil isClosure.
  ^self return: self pop from: self!

Item was changed:
+ ----- Method: Context>>pushConsArrayWithElements: (in category 'instruction decoding') -----
- ----- Method: Context>>pushConsArrayWithElements: (in category 'instruction decoding (closures)') -----
  pushConsArrayWithElements: numElements
  | array |
  array := Array new: numElements.
  numElements to: 1 by: -1 do:
  [:i|
  array at: i put: self pop].
  self push: array!