POS

[Paul Prescod]

Harvey J. Stein wrote:
>  > Now imagine that I'm ray tracing. I'm using a lot of RAM over several
>  > days. I do *not* want my local data to take up space. I do *not* want
>  > them to use disk space even while the program is running. I do *not*
>  > want to waste time saving these objects to disk every so often.
> 
> Why not?  Are you doing a ray tracing that takes several days?  If so,
> do you want to have to start it again if the machine crashes?  

Maybe. Two days of computer time is not that valuable unless I have a
deadline. Also it could be the case that I *know* that the job will take
two or three times as long if things are checkpointed. The more often
they are checkpointed, the slower the job. For the other job, email, I
want REALLY often checkpoints. For this job I want *NO* checkpoints. For
some jobs I want checkpoints only at particular times (e.g. after every
100 keystrokes).

> What
> about swapping to disk inactive memory because half of a large chunk
> of your image has already been computed so as to free up ram for other
> applications?  

That might be a good idea. It might be bad idea. It depends on the
system's goals. Checkpointing an HTTP server seems to be a similar waste
of time. There may be a LOT of objects in memory at once, because they
are being served to the Web, but NONE of them are worth saving to disk.0

>And if you checkpoint again after the ray tracing is
> done, then that'd have the effect of freeing disk space.

Sure, but will I even have the option of explicit, manual checkpoints or
is everything just "automatic."
 
>  > Right, but local variables must get saved too. That's what someone was
>  > saying about how difficult it is to save the stack under Unix.
> 
> Well, in the simple situation, one calls (dumplisp) from the top level
> environment and the environment isn't multithreaded.  I guess what
> you're saying would hold in a multithreaded environment if one were to
> try to checkpoint while other threads are running.  I guess it hasn't
> come up for CMUCL because it doesn't have threads.  What does ACL do
> in this situation?

As I understand it, the transparent POS proposal does not HAVE a
(dumplisp). (dumplisp) is implied. Every object write is implicitly
copied to disk, perhaps asynchronously.
 
> Correct me if I'm wrong, but it the only way seems to be to not make
> object saving transparent - to put it under application control, in
> which case you loose alot of the beauty of a tranparent persistent
> store, which is to say that you have to go about figuring out exactly
> how to save your state.  Unless it's merely a matter of saying which
> global variables one cares about.

We obviously have to think about this more, but if the choice is between
making things hard for the user, by hiding large objects under
unscruitable programmer-names or hard for the programmer, by requiring
explicit object loads and saves, I would favour the user. Note that I am
absolutely *not* suggesting we go back to the bytes and files model. I
think that the "file system" should be an object oriented store and
programs that really want to save ALL of their state should do so using
a (save-my-state "foobar") function. But I expect this to be the
exception rather than the rule.

 Paul Prescod