On Wed, Aug 17, 2011 at 10:22:16AM -0700, Xinliang David Li wrote: > On Wed, Aug 17, 2011 at 8:35 AM, Mike Hommey <mhom...@mozilla.com> wrote: > > On Thu, Aug 11, 2011 at 09:27:23AM -0700, Xinliang David Li wrote: > >> > Maybe I have an idea as to why FDO doesn't work so well. Does the > >> > instrumentation code support running several times in parallel (as in, > >> > several processes with the instrumented code running concurrently)? > >> > >> gcc supports profile merging from multiple runs -- but there is no > >> synchronization on profile file update, but it will become a problem > >> only when all the concurrently running processes are existing at the > >> same time (and dumping profile data to the same gcda file at the same > >> time). Similarly, there are data races in profile counter update for > >> multi-threaded programs, in practice it is not a big issue > >> (-fprofile-correction option needs to be turned on in profile-use). > > > > Are there known quirks with threads and dlopen() ? > > threads causes data races in counter update, but the problem is minor > in practice. > > dlopen should also be fine. libgcov is linked in statically into each > shared library, so dlopen/dlclose won't mess up other shared lib or > main executable's module list. > > > > > To avoid the problem mentioned above, I configured Firefox to use only > > one process. But in that setup, I only get partial instrumentation data. > > For example, I get instrumentation data for cairo, but not for our > > layout engine. I do however get layout engine instrumentation data with > > the same build if I enable multiple processes (but then I hit the > > problem that multiple processes updating the same profile data is not > > properly supported). > > Are they exiting at the same time? If not, it should be fine.
They are, and communicate with each other. Mike
