Re: [Gc] Re: Performance of bdwgc7.2 had degraded compared to 6.8 - the patch to test

[Ivan Maidanski]

Hi Ludovic,

Please don't hurry to blame yourself ;)

Strange but the bigloo tests show the degradation problem has nothing with the patches below.


Thu, 02 Dec 2010 21:53:09 +0100 ludo at gnu.org (Ludovic CourtХs):

> Hi Ivan,
> 
> Ivan Maidanski <ivmai at mail.ru> writes:
> 
> > It seems the observed degradation can be discovered by 2 tests:
> > 1) by benchmarking v71 vs v72a2+test2_patch;
> > 2) by benchmarking v71 vs v72a2+test3_patch.
> >
> > test2 patch reverts the relevant changes of:
> > 2008-08-21  Hans Boehm <Hans.Boehm at hp.com>
> >
> > test3 patch reverts the relevant changes of:
> > 2009-05-22  Hans Boehm <Hans.Boehm at hp.com> (Largely from Ludovic
> Cortes)
> 
> Damn, I feel guilty now.  ;-)
> 
> Did you measure the effect of each patch individually?  It would be
> interesting to know.
> 
> For the record, the discussion that led to the second patch started here:
> 
> http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2570
> 
> The next-to-final patch was posted here:
> 
> http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2634
> 
> The intent was to /exclude/ ELF sections containing relocated read-only
> data from the GC roots on GNU systems, thereby reducing the amount of
> memory that needs to be scanned.
> 
> The effect on libguile was discussed here:
> 
> http://thread.gmane.org/gmane.lisp.guile.devel/9247
> 
> In this message, I wrote:
> 
> However, when not linking with `-z relro', static allocation leads to
> slightly degraded performance and increased heap usage (perhaps due to
> misidentified pointers in the `.data.rel.ro' section?).  This is
> probably worth some investigation on the BDW-GC side.
> 
> So, ahem, I feel twice as guilty now...
> 
> Could the problem be caused by the search for LOAD segments when a
> PT_GNU_RELRO is encountered, in GC_register_dynlib_callback?  The code
> does:
> 
> --8<---------------cut here---------------start------------->8---
> for( i = 0; i < (int)(info->dlpi_phnum); ((i++),(p++)) ) {
> switch( p->p_type ) {
> case PT_GNU_RELRO:
> /* This entry is known to be constant and will eventually be remapped
> read-only.  However, the address range covered by this entry is
> typically a subset of a previously encountered `LOAD' segment, so
> we need to exclude it.  */
> {
> for (j = n_load_segs; --j >= 0; ) {
> --8<---------------cut here---------------end--------------->8---
> 
> It does look quadratic to me.
> 
> However, it would only impact initialization time, which is probably
> negligible on long-running programs (such as the Bigloo benchmarks, I
> suppose).
> 
> Hmm, OTOH, GC_is_visible calls GC_register_dynamic_libraries, which runs
> the above code, so this could be a problem.
> 
> What do you think?
> 
> Thanks,
> Ludo'.
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/