[Ns-developers] ns3: boehm garbage collection

[Gustavo Carneiro]

On 1/31/07, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
>
> On 1/31/07, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> >
> > On 1/31/07, Mathieu Lacage <mathieu.lacage at sophia.inria.fr > wrote:
> > >
> > > On Tue, 2007-01-30 at 18:29 +0000, Gustavo Carneiro wrote:
> > >
> > > > >   (+) Doesn't add any per-object memory overhead (like reference
> > > > > counting);
> > >
> > > Right, but then, how does the GC keep track of which memory areas were
> > > allocated ? I suspect that you will find the overhead somewhere else.
> >
> >
> >    Right.  I googled a bit and found a Mono page (http://www.mono-project.com/Performance_Tips
> > ) saying that "Each object has an 8 byte overhead (4 to tell what type
> > it is, then 4 for a sync block)."
> >
> >   But then again, boehm GC implements its own allocator that avoids
> > per-object system malloc.  Surely the system malloc, which is avoided here,
> > also has some similar overhead, so things might even out.  Unfortunately I
> > was unable to find out what is the overhead associated with e.g. glibc
> > malloc.
> >
> >   When googling for this I found a Linux Journal article discussing the
> > advantages/disadvantages of the Boehm GC.  Interesting experiments they
> > conducted:
> >
> > "The overall execution time, on box A, was 3.80 seconds with traditional
> > > management and 2.43 seconds with GC, an improvement of about 35%. The
> > > same test performed on box B showed an even greater improvement, around 40%.
> > > *This first test shows that, contrary to popular belief, GC actually
> > > can be quite faster than malloc/free."*
> > >
> > *
> > *  Good news, speed-wise.  Later in the same article:
> >
> > * *
> > >
> > > "Heap expansion is greater in the GC case, with a value of 1.7 vs. 1.0
> > > ."
> > >
> >
> >   So, it is true that program using GC uses more memory.  But I suspect
> > that is more to the fact that memory release with GC is delayed wrt. to
> > manual free()ing.  But, yes, in practice the delayed deallocation of the GC
> > will mean we may need more RAM to run a program... that is a downside :|
> >
>
> I tweaked the test-gc program to make it produce two programs: one uses
> GC, the other one uses normal new/delete:
>
>   http://telecom.inescporto.pt/~gjc/ns-3-waf-gc/?rev/32179c8f20ff<http://telecom.inescporto.pt/%7Egjc/ns-3-waf-gc/?rev/32179c8f20ff>
>
>  The results seem to show that, for this particular test program (which is
> probably not representative of a typical simulation), with and without GC
> the result in terms of CPU and memory is more or less the same.
>

  Oops, please ignore my last post, I'm having problems in the build
system.. :|

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."