[fedora-java] Oprofiling Eclipse startup (x86)
Andrew Haley
aph at redhat.com
Wed Jun 8 09:20:30 UTC 2005
Anthony Green writes:
> On Tue, 2005-06-07 at 16:38 -0400, Andrew Overholt wrote:
> > Hi,
> >
> > I've spent a bit of time doing some more $subj. These reports (and
> > samples) were taken with --no-vmlinux. Please tell me if there's something
> > else I should be doing.
>
> I recently checked in a change to the GCC 4.0 branch that saves over 10k
> exceptions and related memory allocations during Eclipse startup.
>
> This change appeared in today's gcc-4.0.0-11. Is this what you're
> using?
It seems the profile is spending much of its time inside the exception
unwinder. This might be due to the fact that Eclipse uses a huge
number of shared libraries, enough to blow out the cache.
To explain: in libgcc we have a cache used for unwinding. The cache
tells us which shared library contains the PC. Whenever we look up a
PC value, we look in the cache. Each cache element contains pc_low
and pc_high.
There are 8 cache entries, which is sufficient in almost all cases.
However, Eclipse has a huge number of libraries, and I suspect the
cache is being flushed every time. The reason I suspect this is the
large number of calls to search_object().
It is also possible that there is some problem with unwinder data.
This will cause a linear search to be done instead of a binary search.
> Also, are you using FC4's oprofile, or the one from oprofile cvs?
>
> See
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157854
>
> Your profiles look a little bit like the bogus ones I reported.
I think so. I don't believe 8% of total time inside __do_global_ctors_aux.
Also, search_object() is being called a huge number of times but none
of the routines that it calls appear in the profile. This is
impossible.
Andrew.
static const fde *
search_object (struct object* ob, void *pc)
{
/* If the data hasn't been sorted, try to do this now. We may have
more memory available than last time we tried. */
if (! ob->s.b.sorted)
{
init_object (ob);
/* Despite the above comment, the normal reason to get here is
that we've not processed this object before. A quick range
check is in order. */
if (pc < ob->pc_begin)
return NULL;
}
if (ob->s.b.sorted)
{
if (ob->s.b.mixed_encoding)
return binary_search_mixed_encoding_fdes (ob, pc);
else if (ob->s.b.encoding == DW_EH_PE_absptr)
return binary_search_unencoded_fdes (ob, pc);
else
return binary_search_single_encoding_fdes (ob, pc);
}
else
{
/* Long slow labourious linear search, cos we've no memory. */
if (ob->s.b.from_array)
{
fde **p;
for (p = ob->u.array; *p ; p++)
{
const fde *f = linear_search_fdes (ob, *p, pc);
if (f)
return f;
}
return NULL;
}
else
return linear_search_fdes (ob, ob->u.single, pc);
}
}
More information about the fedora-devel-java-list
mailing list