Re: ongoing frysk.proc.ptrace refactoring

[Andrew Cagney <cagney@redhat.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
>>>
>>>     
>>>       
>>   
>>     
>
>