This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: reverse trace [was: vmware's replay framework and gdb]


> One of the reasons I was thinking of relational databases was that they can
> deal with the volume and put whatever the decide to cache into dis instead of
> memory (but maybe you were thinking disk space when you said memory anyway).

RAM, disk, does not matter -- size is enormous either case. 
 
> Besides compression of data stream there is also the possibility of only
> caching at certain sync points and tracing between sync points you have to
> regenerate the temp variables, etc.  Like I said, I was just brain storming
> here.  I had no idea how far things had gotten along the lines of
> Chronomancer/Chronicle.
> 
> Regardless of how it eventually ends up working, it is going to either use a
> LOT of space, or a lot of CPU power to recreate.

The CPU power is actually easier to handle, especially if you have a few
snapshots to return to along the way.  We have looked at this hard, and the
execution to recreate is much easier to make scalable than the complete trace
approach.

/jakob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]