[Ns-developers] ns3: boehm garbage collection
gjcarneiro at gmail.com
Wed Jan 31 06:30:02 PST 2007
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:
> 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
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."
More information about the Ns-developers