Using CCodeGenerator for something beyond Plugins

Tim Rowledge tim at sumeru.stanford.edu
Wed Mar 20 17:12:24 UTC 2002


Anthony Hannan <ajh18 at cornell.edu> is claimed by the authorities to have written:

> Pre-compiling a whole Squeak image to native code would not be better
> than just-in-time compiling primarily because native code takes up a lot
> more space than bytecodes.  It is better to only compile bytecodes that
> are needed.
Good points, but I can see some possible workarounds that would alter
some of the factors involved.

First, doing translation on demand just as with typical dynamic
translation but don't worry about having a set cache of translated code
that needs separate management (c.f. visualworks) rather keep the native
code array in-image attached to the 'normal' method. This leaves the
memory management to the usual tools. As I've suggested before, the
translation could be at the time it is asked for via some in-the-vm
subsystem, or queued up for handling by a background process translator
whilst work continues using an interpreter. This might be interesting
since it would allow some heuristics to be applied to work out whether
the transation is actually worth doing. For example, almost none of the
code relating to image startup is worth the effort since it only runs
once.

Second, keep the translated methods segregated so that they can be
dropped quickly, in a similar manner to ImageSegments. Thus we can
snapshot without the native code cluttering up the image (and
avoiding having to check for 'is this the same architecture as it was
compiled on' for each activation) on disc.

Third, allow a variety of ImageSegment (or maybe module would be good
for this?) which contains pre-translated native methods for critical
areas of the system, thus avoiding the cost of doingthe work at actaul
runtime. Obviously there would have to be separate chunks for each
architecture, checking at load time etc.

Fourth, use some sort of pointer-strengthening algorithm to help with
garbage collecting little used but still translated methods. Perhaps
initially give each method a weak link to the translated code and
convert it to a 'full' link once it has been executed a couple of times?
Maybe timestamp that link and occasionally sweep by turning it back to
weak to se if the code is still really used? All sorts of possibilities.

Fifth, let's design a CPU with a nice large chunk of memory on-chip
(128Mb would do) running at full cpu speed and completely under software
control (no daft hardware algorithms to flush stuff please) that can
contain most of the system. An ARM5TE architecture with no caches
(wouldn't need them with 128Mb onboard full speed memory) would make a
good start.

Sixth. Err, oh yes, world peace and feed all the children.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
USER ERROR: replace user and press any key to continue. 




More information about the Squeak-dev mailing list