3 ms·

I don't really understand the premise. So presumably you can't "reverse" A = B because you lost the old value of A, right? OK, but why did you lose that? If you

I don't really understand the premise. So presumably you can't "reverse" A = B because you lost the old value of A, right? OK, but why did you lose that? If you took the time to pause before that instruction and write down B, why didn't you just save the value of A as part of that step too? Is it a speed or space issue?

seoaeu 4y ago
The problem is that A might be overwritten many times between snapshots. So you may know one value for A, but you have to simulate execution forward to find out the specific value it had when execution reached that line.
- dataflow 4y ago
  Ohh, I was thinking of single-stepping. I didn't realize snapshots are so coarse. Makes sense for memory usage, I see. Thanks!
mark_undoio 4y ago
As seoaeu says, we only have the values at the snapshot times and need to recompute in between. We're not actually logging changes to variables, we're only logging outside information that changes the course of the computation. The variables are a result of that computation and not something we store directly. So there's no explicit saving of A when we set it to B - and hence no opportunity to save the previous value of A either. The reasons are both speed and space, as you suggest, but also fidelity of recording. * If we recorded all variable values explicitly it could become very slow to run real world programs due to the extra work being done. * Recording all changes could also use a lot of storage for even trivial behaviours - e.g. for (i = 0; i < 10000000; i++); * Even if you log normal variable values you still have to worry about uninitialised memory, stray pointers, use after free - i.e. sources or destinations of assignments that aren't captured clearly in C language semantics. If we want to catch arbitrary bugs we do need to act at a level below normal-case language behaviours. A side effect of this is that the underlying low level engine can record other languages with a different layer on top to handle language-specific semantics - that's what we do for Java.

seoaeu 4y ago

The problem is that A might be overwritten many times between snapshots. So you may know one value for A, but you have to simulate execution forward to find out the specific value it had when execution reached that line.

dataflow 4y ago
Ohh, I was thinking of single-stepping. I didn't realize snapshots are so coarse. Makes sense for memory usage, I see. Thanks!

mark_undoio 4y ago

As seoaeu says, we only have the values at the snapshot times and need to recompute in between. We're not actually logging changes to variables, we're only logging outside information that changes the course of the computation. The variables are a result of that computation and not something we store directly. So there's no explicit saving of A when we set it to B - and hence no opportunity to save the previous value of A either. The reasons are both speed and space, as you suggest, but also fidelity of recording. * If we recorded all variable values explicitly it could become very slow to run real world programs due to the extra work being done. * Recording all changes could also use a lot of storage for even trivial behaviours - e.g. for (i = 0; i < 10000000; i++); * Even if you log normal variable values you still have to worry about uninitialised memory, stray pointers, use after free - i.e. sources or destinations of assignments that aren't captured clearly in C language semantics. If we want to catch arbitrary bugs we do need to act at a level below normal-case language behaviours. A side effect of this is that the underlying low level engine can record other languages with a different layer on top to handle language-specific semantics - that's what we do for Java.