[Squeak-e] Programming the VM
Colin Putney
cputney at whistler.com
Mon Feb 3 11:15:13 CET 2003
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
More information about the Squeak-e
mailing list