Re: industrial use of 'record' and replay.

[Edward Peschko <horos11@gmail.com>]

>> However, I had a few questions, about 'scaling up' the use of this:
>>
>>     1. Suppose that one has an extremely long process, one
>> which takes hours to
>>         'get' to the bug.. How can one 'short circuit' this process so
>> that you don't need
>>         to replay for hours to get to it?
>
> I'm not sure I understand.
> Do you want to avoid the 'long execution' all together or do you want
> to avoid executing it with Recording enabled?  Can you predict about
> where in the program the bug occurs?

What I want to do is record a program, but not necessarily have to replay it
from the start of its recording - ie: have the system automatically
take 'snapshots'
of the state at given intervals, and then have the ability to replay
from any given
snapshot.

Since this would be used in a test suite, I'd like it to be
automatable, ie: set up
in a config file, and then run without any interaction with the user.
One could then
run the test suite, and in the case of 'interesting events' take the
latest version
of the snapshot and run it from that point (rather than from the
beginning of the run,
which may be hours before). If the 'true' bug lies before the latest
snapshot, go
back to the previous snapshot (and the one previous) until the bug
itself is found.

Anyways, looking at your reply and reading about checkpoints, I'm not
sure if they
apply here. Maybe someone more familiar with the internals of record/replay can
comment..

Thanks much,

Ed