From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13265 invoked by alias); 22 May 2007 16:32:17 -0000 Received: (qmail 13063 invoked by uid 22791); 22 May 2007 16:32:16 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 May 2007 16:32:09 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4MGVuYU022202 for ; Tue, 22 May 2007 12:31:56 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4MGVuMq021440 for ; Tue, 22 May 2007 12:31:56 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4MGVsYt032540; Tue, 22 May 2007 12:31:54 -0400 Message-ID: <46531B07.4010005@redhat.com> Date: Tue, 22 May 2007 17:08:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: Chris Moller CC: frysk Subject: Re: ongoing frysk.proc.ptrace refactoring References: <4652FE1B.8000004@redhat.com> <46530068.2090807@redhat.com> <46531685.7090405@redhat.com> In-Reply-To: <46531685.7090405@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00192.txt.bz2 Chris, Good question. The existing code-observer code modifies memory by inserting small breakpoint instructions (1 byte on i386, 4 bytes on PPC and 8 bytes? on ia64) and going forward will write slightly larger chunks (~16 bytes) so efficiency there may be helpful. Beyond that, however, no existing code is attempting large memory writes so justification for the change is absent. Andrew Chris Moller wrote: > I just committed this stuff. You should be able to drop > MemorySpaceByteBuffer in as a replacement for AddressSpaceByteBuffer and > get a huge increase in performance in multi-word peeks. > > Does anyone need high-speed multi-word pokes? The StatelessFile class > supports that, but AddressSpaceByteBuffer doesn't, so I didn't include > it in MemorySpaceByteBuffer. If there's enough popular demand (>= 1 > request), I'll hack it in. > > Let me know if it blows up in your face... > > cm > > Chris Moller wrote: > >> Andrew, >> >> I'd planned to add MemorySpaceByteBuffer.java and commit a few changes >> to TestByteBuffer.java in frysk-core/frysk/proc/ptrace later today--is >> that going to mung up the stuff you're doing? >> >> Chris >> >> Andrew Cagney wrote: >> >> >>> Just a work-in-progress update: >>> >>> While I've finished restructuring the target specific frysk.proc code >>> into separate frysk.proc.corefile, frysk.proc.dummy and >>> frysk.proc.ptrace packages there's still a ways to go as the >>> refactoring has helped clarify several additional problems with the >>> current code: >>> >>> -> frysk.proc.Proc and frysk.proc.Task seem to have gained a number of >>> fields, such as Task.sig_send, that are very Linux/ptrace centric; >>> the'll need to be cleaned up >>> >>> -> many of the methods, such as frysk.proc.Task.sendContinue, being >>> ptrace specific (they do not apply to a corefile proc), can be moved >>> to more specific packages >>> >>> -> rather than split along the lines of "corefile" and "ptrace", a >>> better split might be "dead" (you can query a dead proc) and "live" >>> (or stateful) (you can observe a live proc), re-consider that once the >>> more pressing issues are addressed >>> >>> I'll be continuing with this. >>> >>> Andrew >>> >>> >>> >> >> > >