[Vm-dev] image format suggestion

[Jecel Assumpcao Jr.]

Eliot Miranda wrote:
> On Thu, Sep 12, 2013 at 5:27 PM, Tim Rowledge wrote:
> 
> > Another possibly interesting approach would be to use the zip compander
> > we already have in the plugin to just zip the images. Many, many years ago,
> > dan Lanovaz did some experiments with VW to try out the idea and it
> > looked an interesting way to save space and (depending upon machine
> > details) time when loading. Of course, disks are so big these days maybe
> > it doesn't matter, though I've always had a hard time really accepting that
> >. I grew up with  20Mb disc as the Disk Of Your Dreams
.
> 
> I actually implemented this in VisualWorks in the mid 2000's.  It is very simple
> and works well.  I'll put it on the list.  I much prefer it to an ad-hoc scheme
> such as the one Jecel suggests.  Much less maintennance effort.

This is included in the Self VM (it can accept either a .snap or a
.snap.gz file) and I thought I had also seen it in Squeak. I know that I
have tested the compression rate of images from both Squeak and Little
Smalltalk (which does use an odd encoding instead of memory dump) with
gzip and, if I remember correctly, the results were better than my own
scheme by a small factor.

The advantage of my suggestion was a single image format for both 32 and
64 bit VMs, which you don't get with compressed memory dumps. In the
project where I used that encoding I was bootstrapping a Smalltalk with
nothing more than an assembler, so that alternative was simpler than
writing my own version of gzip. That isn't an issue for Squeak, of
course.

In another email, Eliot Miranda wrote:
> On Fri, Sep 13, 2013 at 1:48 AM, Bert Freudenberg wrote:
> > A slightly related idea is "perm space" à la VisualWorks, which makes a part
> > of the object memory read-only.
>
> Actually copy-on-write, with writes minimised by avoiding garbage collecting
> permSpace unless one does a truly global GC. 

If a VM can load more than one image (an interesting thing to do with
multicores) then this space can be shared among them to avoid multiple
copies filling up the machine's RAM. And you can save it to a separate
file on disk to make images smaller (just like the .sources file is only
there to make the multiple .changes you have on a disk be smaller than
they would otherwise be).

In fact, I suggested some applications of this feature in
http://wiki.squeak.org/squeak/584

-- Jecel