Re: [DynInst_API:] Do not trace children

[Matthew LeGendre <legendre1@xxxxxxxx>]

I think using a callback that detaches on fork would remove that 
first-time penalty.
Since Dyninst follows forks and execs by default, it's opening and parsing 
the gcc executable when your application calls system().  Dyninst is 
caching the results of its open and parse, so the subsequent invocations 
are happening much faster.
If you start detaching immediately after fork, then Dyninst should never 
see the exec and will never parse the gcc executable.  That said, I'm not 
sure whether detach will improve the subsequent times.  That'll depend on 
whether Dyninst detaches faster than it handles new process creation 
(which I've never measured).

As Bill mentioned, if Dyninst knew this fork() would be immediately 
followed by an exec() it could make some optimizations and you'd probably 
get close to the 0.03 ~ 0.04 times.  Those optimizations could be turned 
always on with a few small changes inside Dyninst, but the resulting 
Dyninst would have unsafe behavior on apps that fork() without exec().  I 
could point you at what to change, but it's getting into unsupported 
territory.
-Matt

On Thu, 29 Jan 2015, Gerard wrote:
> Hi,
> Thanks for your answers. I'll try using a callback. 
>
> I'm instrumenting a process that at some point compiles a code invoking gcc trough the system() function. I have made more tests and I see that the slow down is worse in the
> first call, does this makes sense?
>
> Those are the times that I observe while I'm instrumenting with dyninst (just the function that wraps the call to system()):
>
> Compilation time 0: 0.984198
> Compilation time 1: 0.080625
> Compilation time 2: 0.084245
> Compilation time 3: 0.077437
> Compilation time 4: 0.084535
> Compilation time 5: 0.111851
> Compilation time 6: 0.087407
> Compilation time 7: 0.090078
> Compilation time 8: 0.093158
> Compilation time 9: 0.075809
>
> While without dyninst the times are between 0.03 ~ 0.04 seconds.
>
> Gerard
>
> 2015-01-20 18:37 GMT+01:00 Bill Williams <bill@xxxxxxxxxxx>:
>       On 01/20/2015 11:22 AM, Matthew LeGendre wrote:
>
>             The closest you can get is to register a callback that triggers on fork,
>             then detach from the child in that callback.
>
>             There's not really a faster way to disable tracing of children, as
>             Dyninst needs to clean its instrumentation from child processes before
>             detaching.
>
>       I'm also somewhat curious what aspect of Dyninst's fork behavior is responsible for the slowdown you're observing, Gerard. Can you tell us a bit about your use
>       case and more details about why/how Dyninst is responsible for this slowdown?
>
>       Matt is of course correct that if this is a fork without a subsequent exec, that it's necessary for Dyninst to remove all its instrumentation. In principle, if we
>       knew that all forks would be followed either by an immediate exec or a crash, we could dispense with that instrumentation entirely, but in practice that's not
>       generally a safe assumption.
>
>       Another option that may be effective is performing the initial instrumentation with binary rewriting...that should have substantially better behavior for what you
>       want re: fork/exec.
>
>             -Matt
>
>             On Mon, 19 Jan 2015, Gerard wrote:
>                   Hello,
>                   Is it possible to not trace the children created by a mutatee? I want to
>                   avoid the time penalty introduced by dyninst when a mutatee creates a
>                   children.
>
>                   Thanks,
>
>                   Gerard
>
>
>             _______________________________________________
>             Dyninst-api mailing list
>             Dyninst-api@xxxxxxxxxxx
>             https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>
>
>
>       --
>       --bw
>
>       Bill Williams
>       Paradyn Project
>       bill@xxxxxxxxxxx