Re: New binaries

Hi Dave,

On Jan 2, 7:45=A0pm, Dave Mason <[email protected]> wrote:
> Thanks, Stephen. =A0As the person active on this list who has their
> fingers most in the code, your explanations are really appreciated!

No problem, I'm always keen to get more people involved on either the
VM side or the Smalltalk image side. Any support I can provide to
enable that I am happy to give.

>
> > The garbage collector involves inverting every oop (pointer to an objec=
t) during the mark phase. What is your interest in forking the VM?
>
> An alternative GC could help with that, obviously. =A0I'm interested in
> scaling by forking to thousands of processes, each to handle 1 active
> user. =A0If the private data could get to be on the order of a megabyte,
> this could be interesting.

That is certainly true, however, at some stage you are going to need
to GC all of old space, or else you run into the same kinds of
problems as JVMs do where PermSpace (which is where Sun's JVMs at
least load classes, methods and such) overflows.

>
> > Understood. At the stage, your only option would be to manually remove
> > classes from the image. This would very much be a trial and error
> > affair. I couldn't give you a list of the minimum set of classes
> > required (though there are some pretty obvious requirements - Object,
> > Array, SmallInteger, etc.).
>
> I'm hoping Dave Griswold can give some hints on how to load the
> sources to build up an image. =A0I presume I it's easier to figure out
> loading classes than removing them.

I had a chat with Dave about this a couple of years ago. At the moment
the only way I know of to compile Smalltalk code to Strongtalk
bytecode is from within an image. That presents a few challenges: how
to compile the source for a subset of classes that are to be filed
out, how to keep that subset of compiled code separate from the code
running in the image, how to save just that subset of classes as a new
image and, perhaps trickiest of all, how to identify the necessary set
of classes and methods to support a given application.

There are a couple of things that could help with some of this.

1. Much of the code in the image doesn't reference the Smalltalk
system dictionary (which is actually a class in Strongtalk) directly,
but instead refers to an alias Delta. One could potentially use this
when compiling the subset of code as an alias for the repository of
compiled classes to be filed out. Any remaining references to
Smalltalk could be replaced with a reference to Delta.

2. The saving of the image occurs in Smalltalk code, rather than in
the VM, via the class Dumper. This collaborates with objects and their
classes to file out the necessary contents of the image file. A couple
of changes would probably be needed to this scheme to ensure that
dumping an image didn't leak out and grab objects and classes that
were part of the required set, but in principle the Dumper could be
subclassed to override the systemDictionary, and a couple of the
helper methods would need to be changed to defer to the Dumper when
looking up the class of an object. (eg. you want your version of
Array, Object, etc., not the version from the running image).

When the image is loaded on startup, code in the VM performs the
reverse of the dumping to load the initial set of classes into object
memory. You will find the core of this loading code in the method
bootstrap::parse_file().

>
> > These all sound like production issues though, and Strongtalk is not
> > nearly at production quality, yet.
>
> Well, there's production and there's production. =A0Obviously Socket is
> a prerequisite for much interesting work.

Oh, absolutely, I just wanted to set expectations up-front.

Cheers, talksmall

--

You received this message because you are subscribed to the Google Groups "=
Strongtalk-general" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to strongtalk-general+unsubscrib=
[email protected].
For more options, visit this group at http://groups.google.com/group/strong=
talk-general?hl=3Den.