From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11845 invoked by alias); 6 Nov 2008 17:09:52 -0000 Received: (qmail 11734 invoked by uid 22791); 6 Nov 2008 17:09:51 -0000 X-Spam-Check-By: sourceware.org Received: from oden.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 17:09:10 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 7C29126EF6C; Thu, 6 Nov 2008 18:09:06 +0100 (CET) Received: from polhem (c83-253-20-211.bredband.comhem.se [83.253.20.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 5290D26EF23; Thu, 6 Nov 2008 18:09:06 +0100 (CET) From: "Jakob Engblom" To: , "'Edward Peschko'" , References: <5cfa99000811051104v3e6ab5e6m50faddb64de050fe@mail.gmail.com> , In-Reply-To: Subject: RE: reverse trace [was: vmware's replay framework and gdb] Date: Thu, 06 Nov 2008 17:09:00 -0000 Message-ID: <008c01c94032$5fe2eea0$1fa8cbe0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: sv X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00057.txt.bz2 > 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