[Fwd: Re: GCJ vs. C++ in RAM]

[Boehm, Hans]

This doesn't have a very clear-cut answer.  The overhead comes from several sources:

1) Fragmentation.  You run into this with any non-compacting allocator.  The one in
our collector is worse than, for example, Doug Lea's malloc implementation.  (In return,
the allocation path is probably faster.)  If your application maintains a fairly constant
split between object sizes, and most of the space is in objects smaller than 1KB, and
your heap size is at least a few MB, this is probably negligible.  But it isn't
always.

2) "Reserve" heap space to avoid collecting all the time.  In the default configuration,
this should be 30-50% space overhead.  For dynamically linked gcj executables with
small heaps, it can be significantly larger, since the collector will expand the heap
to compensate for the time it takes to scan large root sets.  If you can prune the size
of the library, or explicitly register roots, that will help here.  You can easily
trade off time for space here.

3) Space that's not reclaimed (or not allocated) due to pointer misidentification and
dead pointers that are accidentally left around somewhere.  For most applications
with moderate-sized heaps this is small.  But again, that's not always true.

Of course, other memory management schemes have other sources of overhead.  For reference
counting, if your data structures are naturally acyclic, you are more likely to run
into time than space overhead problems.  You may also want to look at

http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/

Hans


> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Vladimir Levin
> Sent: Tuesday, April 06, 2004 2:12 PM
> To: java@gcc.gnu.org
> Subject: [Fwd: Re: GCJ vs. C++ in RAM]
> 
> 
> Cool, thanks!  Do you have any sense of how much of the heap space is 
> dedicated to the garbage collector? In other words, if Java 
> didn't have 
> the Boehm garbage collector built into it, how much smaller would the 
> heap be? I suspect that if we use C++, we'll use reference 
> counting base 
> classes or something along those lines, so we won't have the 
> overhead of 
> running the gc...
> 
> Vlad
> 
> > Not quite.  4MB on disk, 4MB + 10MB  = 14MB in RAM.
> >
> > I have no idea what a similar C++ program would be.  I am guessing 
> > that the executable could be half as large, but the heap would be 
> > similar for similar applications.
> >
> > Dave.
> 
> 
>