Re: [DynInst_API:] Do not trace children

[Gerard <nouboh@xxxxxxxxx>]

Well, seems that detaching did the trick:

Compilation time 0: 0.122659

Compilation time 1: 0.096926

Compilation time 2: 0.104063

Compilation time 3: 0.104441

Compilation time 4: 0.076877

Compilation time 5: 0.063249

Compilation time 6: 0.066638

Compilation time 7: 0.060207

Compilation time 8: 0.078996

Compilation time 9: 0.062104

It does not detach before handling the new process creation (judging by those times) but at least now I don't have that first time penalty. And thank for the offer but I think that changing Dyninst internals is out of my scope for now :)

Thank you very much,

Gerard

2015-01-29 19:41 GMT+01:00 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