[Enh][VM] primitiveApplyToFromTo for the heart of the enumeration of collections?

Bryce Kampjes bryce at kampjes.demon.co.uk
Fri Sep 15 21:44:47 UTC 2006


At the moment no primitives are re-entered. We don't have primitive
contexts. Changing that is a large design change even if the code
change is small. Normal primitives can use shadowing because there is
no way to capture their execution half way through. In this case that
is not true. Shadowing does not fully hide the primitive as it may
need to be re-entered later. 

This primitive will slow down sends and returns on some architectures
but probably not all. Out of order execution is great at hiding cost
behind other delays. I wouldn't be surprised if there is no cost on
either a PPC or an x86 but there will be on some chips. Any
optimisation of the common case send code will increase the
performance loss caused by this primitive. (1)

It could crash if you save an image on a VM with the primitive then
load it on a VM with the image. This will only happen if one of the
primitives is in an active context. Looking at
internalActivateNewMethod the PC will be set to it's initial value but
that will cause the loop to begin again which could be problematic too.

What happens if you step back into the primitiveApplyToFromTo method
from a debugger? So execution entered via the interpreter and used
the primitive then the debugger (or any tool that simulates bytecode
execution) re-enters the primitive method.

There is maintenance risk if the shadow implementation and the real
implementation get out of sync because the bugs may only occur
when switching from running with the primitive to running without the
primitive. This will definitely happen if you move an image to an
older VM but could also happen if you improve the primitive so it can
be re-entered as bytecode.

Also a primitive failing does not necessarily mean that it can be
replaced by the back-up code. In many cases the method code after a
primitive handles a different set of conditions. Have a look at
Object>>size. In general, no execution engine can assume that it can
ignore a primitive.

Bryce

1) Have a look at commonReturn. The simple case when a method or
block is returning directly to it's caller can be simplified. The
general case needs to handle any unwind blocks that might be walked
over while exiting which the common case will not do. Also the common
case could be coded without the loops which risk branch mispredict
when exiting.



More information about the Squeak-dev mailing list