[fedora-java] Oprofiling Eclipse startup (x86)

[Andrew Haley]

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);
    }
}