[Squeak-e] Programming the VM

[Colin Putney]

On Monday, February 3, 2003, at 10:37  AM, Robert Withers wrote:

> On Monday, February 3, 2003, at 06:22 AM, cg at cdegroot.com wrote:

>> Anyway, that'd probably mean, or could mean, that you'd have an extra
>> slot in these objects pointing to their 'machine', not? When they are
>> instantiated, they get the parent's 'machine' reference unless the
>> parent overrides it (either by setting it after the fact, or more 
>> likely
>> by a something like 'Foo newInNewEnvironment').
>>
>> SqueakVM specialists: how hard is it to add an extra reference to all
>> objects? On Squeak level? On VM level?
>
> I would like to hear a little more about what this 'machine' actually 
> is.  Is it a lexical closure?  Would all objects need to have this 
> 'machine' reference?
>
> Squeak object headers are of variable size.  there are 3 different 
> sizes so it uses 2 bits in the baseHeader to define the header size.  
> 1 word, 2 words, or 3 words are the possibilities, and the fourth 
> value is for dead objects, I believe.  Stephen added an extra word for 
> his LOOM impl, and basically all the code that reads or writes the 
> headers would need to be changed to deal with it.
>
> In thinking about how my eventual contexts and this machine context 
> could be combined, it may be best to give all objects this context 
> structure, which the VM could pack appropriately, and let it be a 
> dynamic descriptor of the state of the reference.   Near, Eventual, 
> Persistent, and Private machine scope attribute could be packed inside 
> of this context.


Whoa, hang on guys. I may be missing something here, but I think we're 
still a long way from making these kinds of decisions. I'm still trying 
to get my head around the idea of multiple levels of virtualization 
which don't involve multiple levels of interpretation. Let's talk 
little more about the concepts involved here before we worry about how 
to lay out object headers in the VM.

Mark, it seems to me that the machines in your virtualization frame 
work are instances of the reified mechanisms I mentioned in my first 
post. This would include things like object memory, interpreter, 
compiler, compiled methods, activation stacks etc. On the hardware 
level these would be actual CPUs, RAM etc. Then we'd have the 
abstractions of these provided by the OS: processes, virtual memory 
etc. Then we have the Squeak-E executable, with *its* abstractions, the 
things I was referring to originally: Class, Compiler, Processor, 
Display, thisContext, MethodDictionary, etc.

At deeper levels of virtualization, it looks like we'd need separate 
reifications of these abstractions, that are limited in scope to the 
virtualization level that we're dealing with. These would effectively 
be capabilities for manipulating the virtualization subtree rooted at 
that (virtual) machine.

Is that making sense?

Colin