Re: ongoing frysk.proc.ptrace refactoring

[Andrew Cagney <cagney at redhat dot com>]

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
> > >
> > >     
> > >       
> >   
> >     
>
>