[BC][VI4] Forked Squeak version

Anthony Hannan tony.hannan at verizon.net
Wed Jun 12 19:13:00 UTC 2002


On 2002/06/11 Ian Piumarta <ian.piumarta at inria.fr> wrote:
> Maybe on a positive note I should add that the single most important
> thing that could be changed in the image to make JITs a *lot* more
> efficient for Squeak would be to make the representation of compiled
> method code and compiled block code identical.  Block bodies should just
> be "anonymous methods"

Done!  A BlockClosure is an object holding captured temp values and a compiledMethod to execute upon #value.  In the activation record, the BlockClosure is the receiver and its compiledMethod is the method.  Blocks and regular objects use exactly the same activation layout.

About the call stack being in the heap/image.
	I did not know that some hardwares have a faster cache just for the hardware stack (zero'th level cache).  I thought that all memory was equal and would get into the cache when used.  So I thought I was improving things, at least for the interpreter, by avoiding copying the receiver and args, and maintaining and clearing used contexts.  Also, in my naivete, I thought we could make the Jitter as simple as inlining the interpreter bytecode actions into the compiled methods, getting enough performance with small translation time and simplicity.
	If you want, we can move my stack implementation out of the image and into the VM.  This way my interpreter will still be faster and your Jitter can ignore it and use the hardware stack.  The debugger and other objects in the image still access contexts via a MethodContext2 object which gets created only when needed and acts as a wrapper to its stack frame.  I can change this wrapper to use primitives that access the stack in the VM.  The only functional difference between the old and new MethodContexts is that new contexts know which process they belong to and are assumed to only be in one process stack.

Cheers,
Anthony





More information about the Squeak-dev mailing list