[SqF]Report of VM Construction Project for Feb '02

Tim Rowledge tim at sumeru.stanford.edu
Fri Feb 1 03:54:04 UTC 2002


This is the initial report for the VM Construction Project group.

Since this is the first such report, I'll start with my view of the
goals of the project.

Goal: The purpose of this project is to create a vm building process and
associated code that makes vm building as simple, reliable and
maintainable as we can manage.

Participants: tim, John McIntosh, Rob Withers, David Lewis, and of
course Ian Piuumarta and Andreas Raab. Other participants to represent
the other vm ports are sought. Stefan Rudlof, Goran Hultgren and others
have provided advise and help.

Background: From the initial release of Squeak, the image has included
all the code needed to create a vm for a Mac. For other platforms there
has been a variety of places and approaches used over time, mostly the
provision of an archive of some sort with a file tree suited to the
platform. Sometimes this has included 'common' files (files such as sq.h
etc) that are derived from but not identical to those in the release
image. This situation could continue into the future without being a
major embarassment to the Squeak community, but some time ago I felt
that it could be improved with some fairly simple changes.

One of the original driving forces for the work that has been released
as the VMMaker and VMMakerTool was the need at exobox to be able to
produce frequent vm builds automatically without extensive user
intervention. Another original aim was to find a way to produce a file
tree that reasonably suited all known platforms and that was compatible
with automated vm production. The time-honoured vm production routine
was not very suited to thise aims. For example, generating the core of
the vm required two unrelated incantations and produced a dump of files
in the current wrking directory; these files needed moving, sometimes
editing, before being compiled. Producing a vm for a Mac required a
different incantation and produced a different group of files. Changing
which set of plugins were produced and whether they were internal or
external, required editing a method.

None of this prevented a rudimentary script from being used succesfully,
but it apearred untidy and suboptimal to some users.

A secondary concern was the scattered provenance of the code for non-Mac
machines and the varied update levels of that code. Using some common
repository was suggested and seemed a sensible experiment. The initial
attempts to use SourceForge mainly served to demonstrate that a better
file organisation would be very helpful.

Current status: The VMMaker has been the major focus of the work for
this project thus far. It is currently able to produce vms for any of
the four most active platform from a codebase stored on SourceForge. A
UI exists that makes it easy to configure the plugins and to save and
use said configurations. The basic tool is scriptable and has been
documented on the swiki and in SqueakNews, as well as having been
demonstrated at OOPSLA. Work is still in progress to bring all platforms
to the same level of compliance (for want of a better word). 

Future Plans: The VMMaker codebase is reasonably complete but there are
enhancements that might be worth pursuing -  makefile (or at least
makefile fragment) production, integration with sqCVS, vm internal
configuration (cache size etc) amongst them. The codebase currently on
SF is in good order, barring the mostly makefile related updating needed
by non-unix platforms, but tools to make it easier to fetch the code in
release-matched sets, to tag release sets, deal with branches and bug
fixes are all needed.

The most important goal is to reach agreement on adopting VMMaker or on
an acceptable alternative. No other interesting alternative is currently
proposed. Once a reasonable level of agreement is reached the artifact
can be integrated into the main release, presumably by creating a module
for it.

tim.
chair, VM construction project.
"We live for the VM, we debug for the VM. But we don't debug stupidly"




More information about the Squeak-dev mailing list