Re: FAQ update

[Jeff Sturm <jsturm at sigma6 dot com>]

Tom Tromey wrote:
> 
> >>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:
> 
> Jeff> If your Java application doesn't need threads, try building
> Jeff> libgcj using --enable-threads=none.  Portions of the libgcj
> Jeff> runtime are still more efficient when single-threaded.  This
> Jeff> will also allow you to use the profiler (gprof) on non-threaded
> Jeff> Java code (POSIX threads seem to be incompatible with the gmon
> Jeff> stuff).
> 
> I've heard reports from a Cygnoid that gprof works ok with threads, at
> least on Linux.  He told me that you can't get per-thread profiling,
> but profiling should work for the process as a whole.  Have you tried
> it and had a different experience?

Hmm... when I built libgcj with POSIX threads, the process still wrote
gmon.out but with no timings.  Without threads I got good profiling data
with timings (that's how I discovered the method_cache bug).  Nothing
else changed... <shrug>

I haven't spent the time hunting down the mcount implementation in glibc
to figure it out.  I suspect it has either unprotected global variables
(causing a race condition) or some atomic update instructions (which are
expensive, particularly on SMP).  The "right way" to do profiling with
multithreading is to give each thread local storage for its profiling
data.  Meanwhile, profiling multithreaded programs either won't work or
will give poor results IMO.  I keep a version of libgcj around built
with -pg and without threads for this reason...


-- 
Jeff Sturm
jsturm@sigma6.com