New binaries
talksmall
new image and sources archive. Recent highlights include
- a major overhaul of the LargeInteger primitives
- Smalltalk code for finalization support
- support of GC Aliens
All feedback welcome. In particular, I'd really like someone to help
exercise the LargeInteger support.
Thanks, talksmall
You can follow me on twitter at http://twitter.com/smalltalkhacker
Dave Mason
installed VMWare Fusion on my MacBook to explore Strongtalk under
Windows, but I can't seem to get to it.
Is it possible to create a version blowing away most of the image and
building it up a la GNU Smalltalk? I think I'd find that much more
approachable.
Thanks ../Dave
talksmall
Not sure exactly what you mean. I'm not familiar with GNU Smalltalk.
talksmall
John Cowan
files: there are no bits in an image that aren't the result of loading
source code. As such, it is more like a Java .jar file than a
traditional ST image.
IIRC, there are bits in the Squeak image that result from global
assignments done under ST-76.
> --
>
> You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
> To post to this group, send email to strongtal...@googlegroups.com.
> To unsubscribe from this group, send email to strongtalk-gene...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en.
>
>
>
--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures
talksmall
Thanks for the explanation.
Strongtalk is a bit of a halfway house between the two. All of the
code resides as compiled methods (bytecode) preserved in the image
between restarts. OTOH, most dynamic state is not preserved between
restarts. So no preservation of windows a la Squeak. Each start is a
fresh state, both for application data and for the native code cache
(though there is an experimental inlining database that can be used to
store and reload the inlining state of compiled methods).
Right now there is no easy way to bootstrap an image from scratch, nor
is there an interactive command line. You can run scripts from the
command line. These are just collections of Smalltalk fileIn chunks,
and are therefore easily editable, though clearly not ideal. In that
sense, I guess, it would not be much different to GNU Smalltalk from a
coding perspective.
Over the next months I hope to add a UI for OSX and then maybe for
Linux. If someone would like to contribute an interactive command line
capability that would be great.
talksmall
On Dec 23, 5:53 pm, John Cowan <johnwco...@gmail.com> wrote:
> In GNU Smalltalk, an image is just a binary cache of loaded source
> files: there are no bits in an image that aren't the result of loading
> source code. As such, it is more like a Java .jar file than a
> traditional ST image.
>
> IIRC, there are bits in the Squeak image that result from global
> assignments done under ST-76.
>
You can follow me on twitter at http://twitter.com/smalltalkhacker
David Griswold
-Dave
Dave Mason
Is there a recipe/script anywhere that builds that image from the
source code? If so, it would presumably be not too difficult to strip
it down to build an image without the Windows (or any) UI (presumably
with an alternate error handler).
I would find that far more accessible than trying to run in Windows
via Fusion (in my 36 year career, I've probably spent less than a
dozen hours on Windows - so I'm a bit crippled in that environment)
This is exciting! There is some work on a SeasideXUL UI, and I have a
grad student who will be working on a portable Seaside UI (a la Web
Velocity), so I'm not very interested in porting the existing UI. I'm
also very interested in building web servers without any UI.
On Dec 23, 11:50 pm, David Griswold <david.griswold....@gmail.com>
wrote:
> In fact, the Strongtalk image in this respect is the same as GNU. The image
> is simply another form of the source code. No non-programmatic objects are
> kept in the image, no global/class/etc variable state is saved etc. The
> image can always be recreated exactly from the source code. It is that way
> exactly because I always hated that image hysteresis (history dependence)
> problem in ST-76.
> -Dave
>
> On Wed, Dec 23, 2009 at 9:53 AM, John Cowan <johnwco...@gmail.com> wrote:
> > In GNU Smalltalk, an image is just a binary cache of loaded source
> > files: there are no bits in an image that aren't the result of loading
> > source code. As such, it is more like a Java .jar file than a
> > traditional ST image.
>
> > IIRC, there are bits in the Squeak image that result from global
> > assignments done under ST-76.
>
> > On Wed, Dec 23, 2009 at 10:02 AM, talksmall <stephenlr...@googlemail.com>
> > wrote:
> > > Hi Dave,
> > > Not sure exactly what you mean. I'm not familiar with GNU Smalltalk.
>
> > > talksmall
>
> > > On Dec 22, 7:48 pm, Dave Mason <dvma...@gmail.com> wrote:
> > >> Good to see someone's still working on Strongtalk - thanks Stephen! I
> > >> installed VMWare Fusion on my MacBook to explore Strongtalk under
> > >> Windows, but I can't seem to get to it.
>
> > >> Is it possible to create a version blowing away most of the image and
> > >> building it up a la GNU Smalltalk? I think I'd find that much more
> > >> approachable.
>
> > >> Thanks ../Dave
>
> > > --
>
> > > You received this message because you are subscribed to the Google Groups
> > "Strongtalk-general" group.
> > > To post to this group, send email to strongtal...@googlegroups.com
> > .
> > > To unsubscribe from this group, send email to
> > strongtalk-gene...@googlegroups.com<strongtalk-general%2Bunsu...@googlegroups.com>
> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/strongtalk-general?hl=en.
>
> > --
> > GMail doesn't have rotating .sigs, but you can see mine at
> >http://www.ccil.org/~cowan/signatures<http://www.ccil.org/%7Ecowan/signatures>
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Strongtalk-general" group.
> > To post to this group, send email to strongtal...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > strongtalk-gene...@googlegroups.com<strongtalk-general%2Bunsu...@googlegroups.com>
talksmall
The short answer is no, there is no build script or recipe for the
image. A bootstrap process for image would be a useful thing to have,
but it's not high on my priority list currently. One thing to note if
you are interested in implementing this is that the Smalltalk compiler
is pure Smalltalk. The only point at which the VM is involved in the
compilation of Smalltalk code is the installation of the compiled
bytecode as a compiled method. This makes bootstrapping trickier than
if the compiler was part of the VM, but it also means you have greater
flexibility over compilation. You can relatively easily replace the
compiler with a different parser or code generator.
However, at roughly 2MB the current image is pretty small, even
without stripping out the Windows dependencies. Note that even though
the image contains platform classes for Windows, OSX and Linux, these
do not load any dynamic libraries unless and until they are actually
required, so there is no real harm (other than the memory occupied by
the classes and methods) in having them in the image. Unless you were
interested in a very constrained embedded application I doubt this
would be significant enough an overhead to worry about.
The stop handler (a block that is called when a Smalltalk Process is
stopped in the VM) can certainly be replaced. When scripting the VM
using the -script command line option the stop handler normally used
by the UI is replaced by a version that invokes the command line
evaluator. This is a very primitive debugger that stops the VM while
debugging a process. You could also replace this with a stop handler
block of your own devising using
Process stopHandler: [:process| ".... handle stop ..."]
If you are interested in porting Seaside, one obstacle you will face
is the absence of continuations (either full or partial) in the
Strongtalk VM. I suspect it would not be all that hard to implement
continuation support, as the basic building blocks are there in order
to support dynamic deoptimization of compiled frames. This would
require VM changes though.
You will also need to implement some Socket classes as there are none
in the image at the moment.
Regards, talksmall
talksmall
On Dec 29, 5:54 pm, talksmall <stephenlr...@googlemail.com> wrote:
> block of your own devising using
>
> Process stopHandler: [:process| ".... handle stop ..."]
should have been
Processor stopHandler: [:process| ".... handle stop ..."].
But you knew that, right? ;)
Regards, talksmall
Dave Mason
> Unless you were interested in a very constrained embedded application I doubt this would be significant enough an overhead to worry about.
Actually, the memory-footprint/image-size isn't my primary concern,
although anything that got moved-around/garbage-collected and hence
would bump actual memory usage following a fork() would be an issue.
The reasons for wanting to be able to minimize the image are 2-fold:
1) for reliability/security/audit reasons, I want to be able to review
all the code in an image, so the less, the better;
2) presumably, the fewer classes, the higher the likelihood that the
compiler can find singleton message dispatch and hence in-line code
and get better performance. (I haven't looked at the compiler, so this
is pure speculation.)
> If you are interested in porting Seaside, one obstacle you will face
> is the absence of continuations (either full or partial) in the
> Strongtalk VM.
Actually, Seaside 3.0 can work without continuations, although partial
continuations are necessary for certain kinds of operations.
../Dave
talksmall
On Dec 31, 7:53 pm, Dave Mason <dvma...@gmail.com> wrote:
> Thanks, Stephen.
>
> > Unless you were interested in a very constrained embedded application I doubt this would be significant enough an overhead to worry about.
>
> Actually, the memory-footprint/image-size isn't my primary concern,
> although anything that got moved-around/garbage-collected and hence
> would bump actual memory usage following a fork() would be an issue.
Well, regardless of whether or not things get moved around, a full
garbage collection will write to every page in object memory that
contains part of an object accessible from the roots. The garbage
collector involves inverting every oop (pointer to an object) during
the mark phase. What is your interest in forking the VM?
>
> The reasons for wanting to be able to minimize the image are 2-fold:
>
> 1) for reliability/security/audit reasons, I want to be able to review
> all the code in an image, so the less, the better;
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.).
These all sound like production issues though, and Strongtalk is not
nearly at production quality, yet.
>
> 2) presumably, the fewer classes, the higher the likelihood that the
> compiler can find singleton message dispatch and hence in-line code
> and get better performance. (I haven't looked at the compiler, so this
> is pure speculation.)
Actually, the JIT compiler only looks at the information contained in
the inline caches within methods that are populated from actual
program execution, so it will only inline code from methods that have
actually been executed as a result of a message send at a particular
call site. This means that the number of classes in an image will not
directly influence the effectiveness of code inlining. The compiler
does not compile all code, only those parts that are executed
frequently enough to trigger recompilation. Even after running for an
extended period, most of the code in the image will not be compiled to
native code, only those bits that have proven to be performance
critical (by tripping the performance counter).
>
> > If you are interested in porting Seaside, one obstacle you will face
> > is the absence of continuations (either full or partial) in the
> > Strongtalk VM.
>
> Actually, Seaside 3.0 can work without continuations, although partial
> continuations are necessary for certain kinds of operations.
OK. You will still need to implement socket support to get this
working. I'd start with this as a first step. Let me know if there's
anything I can do to help with this, and I'll do my best to help out
as time permits.
Regards, talksmall
John Cowan
> On Dec 31, 7:53 pm, Dave Mason <dvma...@gmail.com> wrote:
>
>> Actually, the memory-footprint/image-size isn't my primary concern,
>> although anything that got moved-around/garbage-collected and hence
>> would bump actual memory usage following a fork() would be an issue.
>
> Well, regardless of whether or not things get moved around, a full
> garbage collection will write to every page in object memory that
> contains part of an object accessible from the roots. The garbage
> collector involves inverting every oop (pointer to an object) during
> the mark phase. What is your interest in forking the VM?
I think you are using "fork" in two different senses: Dave in the
sense of forking processes, Stephen in the sense of forking codebases.
Yours for improved communication,
talksmall
Actually, I don't think so. I wasn't referring to forking the
codebase, though I can see how my comment could have been interpreted
that way. I was assuming from Dave's use of fork() that he was
referring to forking an OS (Unix) process rather than creating a
Smalltalk Process by forking a block, and I was wondering why he
wanted to do that in the context of the Strongtalk VM.
Regards, talksmall
On Dec 31, 10:02 pm, John Cowan <johnwco...@gmail.com> wrote:
Dave Mason
fingers most in the code, your explanations are really appreciated!
> The garbage collector involves inverting every oop (pointer to an object) during the mark phase. What is your interest in forking the VM?
An alternative GC could help with that, obviously. I'm interested in
scaling by forking to thousands of processes, each to handle 1 active
user. If the private data could get to be on the order of a megabyte,
this could be interesting.
> 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. I presume I it's easier to figure out
loading classes than removing them.
> These all sound like production issues though, and Strongtalk is not
> nearly at production quality, yet.
Well, there's production and there's production. Obviously Socket is
a prerequisite for much interesting work.
../Dave
On Dec 31 2009, 3:32 pm, talksmall <stephenlr...@googlemail.com>
wrote:
talksmall
On Jan 2, 7:45 pm, Dave Mason <dvma...@gmail.com> wrote:
> Thanks, Stephen. As 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 object) during the mark phase. What is your interest in forking the VM?
>
> An alternative GC could help with that, obviously. I'm interested in
> scaling by forking to thousands of processes, each to handle 1 active
> user. If 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. I 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. Obviously Socket is
> a prerequisite for much interesting work.
Oh, absolutely, I just wanted to set expectations up-front.
Cheers, talksmall