Also maintaining multiple images introduces another problem.  Namely, one of
image management.
If you have 20 or so images floating around trying to remember what is in
which one becomes
confusing I would think.  I'm pretty sure most people would prefer to have
just the one image (or maybe 2 at most).
I don't think its a matter of disk space, but rather of efficiency in both
the image as well as simplifying your life.


Maybe we need something like a differences sorter (as opposed to a change
sorter) that compares the pre-changed image with the post-changed image and
files the binary data differences away somewhere so that they can be
retracted at a later date...sort of like some software installaters work
when applying patches. (Yes I know this will introduce some new problems).

....just thinking out loud...

-----Original Message-----
From: Marcel Weiher [mailto:marcel at system.de]
Sent: Wednesday, September 01, 1999 11:12 AM
To: squeak at cs.uiuc.edu
Subject: Re: Problems with Win32/WinCE VMs - backing out of changes


> From: Bob Arning <arning at charm.net>
>
> On Wed, 1 Sep 1999 15:41:18 +0200 Marcel Weiher <marcel at system.de> =
> wrote:
> >I guess it wouldn't be quite as bad if images were much smaller.  =20
> >After all, it really is rather silly to have 5 or more copies of the =
> =20
> >image, which are probably 99% identical.
>
> Marcel,
>
> While not wishing to argue against improvements in the current =
> architecture, "silly" seems an inappropriate criticism.

The effect of lugging 4-6 MB around when the changes are typically
on the order of a couple of KB, a wastage factor of 1:1000 is silly
to me.  Copying the images + changes files takes a noticable amount
of time on my machine, when it really shouldn't.  Your mileage may
vary.

> Given disk =
> prices on the order of US$0.04 per megabyte, the cost of storing an =
> additional image is well under a dollar. I keep lots of images
around, =
> both current and earlier releases, both pristine and modified.

Cost of storage is really not the problem.

> Often I =
> have more than one up and running concurrently, each particularly =
> suited to the task at hand. I don't see it as a problem, rather I =
> leverage the capacity of my computer to provide an additional
level of =
> isolation between potentially conflicting threads of development.

The situation gets worse with multi-tasking because all that memory
is 'dirty' from the point of view of the operating system, so each
additional Squeak task gets the *full* RAM penalty, just like current
Java VMs do (Of course, Java's footprint is bigger, so the problem
is worse, but structurally it's the same problem).

I consider the good VM systems with mapping, protection, sharing
etc. one of the major benefits of modern UNIX systems (NT to a lesser
extent); they enable a lot of useful functionality and it's a shame
to lose it again.

> Duplicating that level of isolation within one image may take a =
> non-trivial effort to get completely right.

With the current approach (try to split of sub-images, retract
changes etc.) it is probably quite hard, maybe impossible.  A
slightly different approach based on reading/mapping non-mutable
structures into a (smaller) mutable image should be easier,
especially if initial development is done on a machine with real
virtual memory that can be used to guard against/track accidental
writes.

I'd be willing to give it a shot if I had assistance from a
knowledgeable Squeak/VM hacker.

Marcel