From: Bob Arning arning@charm.net
On Wed, 1 Sep 1999 15:41:18 +0200 Marcel Weiher marcel@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
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@system.de] Sent: Wednesday, September 01, 1999 11:12 AM To: squeak@cs.uiuc.edu Subject: Re: Problems with Win32/WinCE VMs - backing out of changes
From: Bob Arning arning@charm.net
On Wed, 1 Sep 1999 15:41:18 +0200 Marcel Weiher marcel@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
squeak-dev@lists.squeakfoundation.org
-
Marcel Weiher -
Serg Koren