tim Rowledge <tim at sumeru.stanford.edu> wrote:
> lex at cc.gatech.edu wrote:
> > It makes a lot of sense to do this in the VM.  Here are some reasons, in
> > decreasing order of importance:
> > 	
> > 	1. The VM has a snapshot primitive, and surely that primitive should do
> > the Right Thing.  For Smalltalk, that means it should be safe.
> That's actually an interesting argument. For example one could claim 
> that it already is safe since it doesn't alter the in-memory image and 
> so you can always recover.

But I mean, it should be safe by itself.  You cannot invoke BitBlt in a
way (or at least, I hope not) that would write data into random places
in memory, and it isn't required that Form is implemented correctly in
order to achieve that property.  This is a good property for a primitive
to the extent it can be achieved.


> > 	2. The exact technique used in my patch (i.e. save to foo.tmp, then
> > rename foo.tmp to foo) is not the only possible implementation.  The VM
> > should be able to use something better (e.g., leverage a transactional
> > filesystem) if such is available.
> > 
> > 	3. It is simple to implement it in the VM.  Maye it's even simpler at
> > the image level, but it can't be by much; there isn't much code there to
> > begin with.
> I think both the above leave me thinkgin image code is better. VM code 
> should be as simple as possible and provide barest-reasonable mechanism; 
> the snapshot prim doesn'y do all the socket suspending, file closing etc 
> , we do that in the image. Likewise, I'd prefer the image to handle any 
> returned error from snapshotting, deal with transactional filesystems, 
> full discs, cosmic ray hits and poor fashion choices.

I don't see how you can think #2 leads to suggesting an image-level
implementation.  What do you do about platforms that snapshot into flash
memory instead of the filesystem, for example?  Do you want every image
to have snapshot code for every kind of snapshot that will be desired on
any platform?  It seems simpler to put platform-specific stuff in the
VM, other things equal.


I also don't see why you think #3 has a suggestion one way or the other.
 We are talking about 1 additional line of code in the VM, plus 1 line
to #define a rename function, plus adding ".tmp" to the end of the save
filename.  This is a tiny change, and it will be extremely simple
whether it is implemented in the image or the VM.  Simplicity of
implementation does not prefer either the VM or the image for
implementing this feature, unless you think #3 is incorrect.



> > 	
> > 	4. It applies to existing images if you implement it in the VM.  Every
> > image I run suddenly has safe snapshots, even if I obtained that image
> > from someone else, and even if the image represents a project I started
> > years ago.
> Hmm, good point.

In particular, it means there is no "the" image....



[later you write:]
> Whatever we decide, it isn't urgent since nothing is about to be changed 
> in the VM until after 3.7 is out. Time to think about it.

There is no "the" VM, either, of course.   Anyone who wants to use the
patch can.  In the meantime, I was not meaning that you personally must
immediately add this patch to the standard VMMaker release; I'm sorry if
my suggestion sounded like that.


> > 	5. It un-applies to all existing images, for people who decide to live
> > dangerously.  If I send you an image, you can run it with dangerous
> > snapshots just by configuring your VM appropriately; you don't have to
> > twiddle a preference in each image you run.
> Not such a good point in my opinion; why add still more complexity in 
> the VM. The damn thing is already too intertwinglulisationated so please 
> let us not add more.

The reason is that this functionality is necessary.  I'm sure you agree
that unsafe snapshots are a Bad Thing.  On the other hand, not all users
have the disk space to support safe snapshots, and so their only option
is to do the current thing and hold their breath while doing it.

Also, regarding complexity, please notice that the image is complicated
too.  I am not proposing complication for complication's sake, and I in
fact I still think I chose the implementation that most reduces
complexity in the overall Squeakiverse.


-Lex


PS -- the ratio of discussion to diff code is not only >1 now, but
probably >10....


PPS -- one of the most frustrating things with the Java world is that
they have frozen their virtual machine spec, thereby making language
improvements even more difficult than they have to be.