In message <20020524220528.86392.qmail at web12508.mail.yahoo.com>
          Tommy Thorn <tt1729 at yahoo.com> wrote:

> Is jitter a seperate package or is it part of
> 
> 
> 
> VMMaker?
No, the jitter stuff isn't part of the VMMaker because VMMaker is just
a toolset to build the vm along with a load of refactoring of the extant
VM code. It should, however, sometime get integrated into the VMMaker
world....

> Why isn't it getting use?
I honestly couldn't give a decent answer to that. Probably words like
'freetime', 'opportunity' and 'laziness' would creep into answer from
most of us!

> I didn't claimed you could, but for the sake of 
> the argument, what stops your from doing 
> send-site caching, even in an interpreter?
> Is the space overhead too big?
Err, you've got me there. I suppose you could actually do some sort of
sned-site cache in the compiled methods; hmm it would cost you a word
associated with each send, which probably adds up a bit but never mind,
some case would be painful (I'm thinking special bytecode sends), mostly
I have a feeling it wouldn't make much diference over the global lookup
cache without the system also having faster send protocols  -  a lot
of saving and restoring goes on in a simpel interpreter which must
surely swamp a relatively trivial lookup). I wonder if it might play
nicely with the different context stack stuff Anthony H did for the
block closures stuff? 


> Excellent.  Is there anywhere I could learn about
> 
> the
> details of the VM implementation on StrongArm?
It's all in the code; see classes Interpreter & ObjectMemory et al. plus
my platform support code on the squeak.sourceforge.net site. All the
interesting stuff is shared by all platforms.

> But, in spite of the poor memory bandwidth on
> the StrongArm, do you think we can speed up
> Morphic enough to make it tolerable?
>
I think so, but I'm willing to bet that the real performance
improvements can be done in the image more than the vm. Morphic does a
great deal of stuff and presents a very big target for optimizations.
And it benefits everybody on every platform (well, nearly always).

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Hardware: The parts of a computer system that can be kicked.