Hi Tim, Ian, and others,

	I don't think we want to go back to ordinary context objects, my
MethodContext2 objects are very similar to Ian's PsuedoContexts.  They
act as interfaces to the stack frame.  Both MethodContext2s and
PsuedoContexts only get created when needed and both affect the stack
frame when manipulated.  I think all I need to do is hide my stack in
the VM, so Jitter can put it on the hardware stack.
	I just have a couple of questions about Jitter which its design
document at
http://www-sor.inria.fr/~piumarta/squeak/unix/zip/j3-2.6.0/doc/j3/ did
not talk about.
	1. How does the garbage collector treat the hardware stack?  Does it
scan and trace it?
	2. How does Jitter handle Smalltalk process switches?  Does it copy the
entire hardware stack into context objects on every process switch?

Cheers,
Anthony


Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> Hi Anthony,
> did you get any luck with that paper of Eliot's? If you have real 
> trouble, I can probably get you a photocopy somehow.
> 
> My best suggestion for progress now is to advise you take a look at 
> getting your blocks and compiler changes to work with ordinary old 
> contexts as in v3.2; I think it should be possible but it may be that a 
> few tiny changes just have to go in. You should find that it simplifies 
> the changes to the image quite a bit. I suspect that you'll find that 
> performance is slightly reduced at this point; after all block 
> evaluation will be a tad more complicated and will involvecreating a 
> blockcontext instead of just (ab)using things the current way.
> 
> Once that is functional, we can consider the best way to improve the 
> stack mechanism in such a way that it doesn't interfere with a jitter. I 
> know it can be done, since I have experience of several Smalltalks that 
> already did it...  :-)
> 
> Consider it a return to obeying Peter Deutsch's old dictum "You can 
> cheat, but don't get caught".