Re: [Squeak-VMdev] DING! End of Round One

[Anthony H. <aj...@co...>]

Dan Ingalls <Da...@Sq...> wrote:
> > > CompiledMethods
> >> A major question to decide is whether to split up bytecodes and literals (and source pointer) as in Tim's NewCompiledMethod work. This adds a little space overhead, but it certainly makes things simpler.  I'm going to assume that we go with Tim's 2-object format, and throw in a "serendipity" field for fun this summer.
> >IIRC the difference is:-
> >header
> >bytecodes
> >literals
> >other ivars
> >
> >or
> >header
> >bytecodes
> >other ivars
> >indexed literals
> >
> >The difference is that to allow adding ivars in subclasses the second
> >option means the VM has to check the number of fixed fields so it can
> >find the literals correctly.

... not if the literal index (stored in the bytecode) includes the fixed
fields.  Then, to the VM, all fields (fixed and variable) are literals. 
If you don't want to waste bytecodes on literals 1 and 2 which will
never get used, just stored literalIndex - 2 in the bytecodes then add 2
in the VM.

Also, I haven't heard anyone mention refactoring the bytecodes (eg.
getting rid of doubleExtendedDoAnythingBytecode).  I bet a JIT would
prefer an alternative encoding.  Are we going to use Eliot's HPS
bytecodes?

Finally, about the Block Closures.  They work with the current image
format so contexts, etc. don't have to change.  A closure object
contains a method (code for just the block) plus an environment (array)
holding values for free variables in that method.  But to save an extra
object the environment is the BlockClosure itself with a single fixed
field holding the method.  The home context is not held in the
environment unless the block can do a remote return.  Also, for free
variables that may change, the environment holds a ValueHolder (actually
a different class that doesn't subclass Model) that is shared amongst
the closure and its outer environments.  Code in the block and its outer
methods access these changeable values by sending get and set messages
to the ValueHolder.  Also ValueHolders have to be created initially by
their home method.  But ValueHolders are rare.  Most free vars are
fixed, so most methods (including home methods whose vars are captured
by blocks) can access their vars directly as usual.

When #value: is sent to a BlockClosure, a new context is activated, the
closure remains as the receiver, and its method becomes the executing
method.  Free vars sit in the indexable slots of the closure but are
accessed as if they were receiver instance variables.  If we change the
bytecodes, maybe we should add the ValueHolder create, get, and set
messages, and the createBlockClosure message as special common selector
bytecodes.

Cheers,
Anthony