gcj mingw32 and java memory footprint.

Boehm, Hans hans_boehm@hp.com
Tue Feb 18 20:49:00 GMT 2003

Gcj, along with nearly all other Java implementations, uses a tracing collector.  In order to discover garbage it has to visit all live objects (and all static memory that might point to them).  It then reclaims unvisited objects.

There isn't really a way to try to reclaim only a subset of the objects, since the collector has to prove that nothing else references those objects.  (That's not quite true.  You can put the collector into generational mode to collect recently allocated objects more frequently and track writes to the heap to some extent.  But it's unlikely that would help much here.  In any case, you can't usefully tell it to try to collect only specific objects.)

The collector is triggered whenever it thinks it has done enough allocation to warrant the cost of the next collection.  Effectively it collects when the amount of allocation since the last GC exceeds a certain fraction of (heap size + root size).  Thus maximum size of the heap should be the maximum live data size times a small constant (theoretically 4/3, typically 1.5-2 due to fragmentation effects and sloppy, but faster, accounting).  You can tune this constant with GC_free_space_divisor, but that's the only easily available knob.

If you think the heap size is much more than a factor of 2 times live data size, it would be interesting to look at a log generated by the GC as a first step.  (Turning on the GC_PRINT_STATS environment variable gives you a very superficial one.  Undefining SILENT in the collector build gives you a better one.  Output of GC_dump() after it has been running for a while is also likely to be informative.  The collector also has more sophisticated heap sampling hooks.  But those aren't yet well-supported in gcj.)  But remember that the live data size includes data allocated by the Java runtime.  It also includes statically allocated data scanned by the collector.


> -----Original Message-----
> From: Norbert Frese [mailto:norbertf@gmx.net]
> Sent: Tuesday, February 18, 2003 7:18 AM
> To: Boehm, Hans; 'Norbert Frese '; 'java@gcc.gnu.org '
> Subject: RE: gcj mingw32 and java memory footprint.
> thanks for answering my questions!
> i try to understand: shrinking can only work when a certain 
> memory page of 
> the heap is 100% garbage. which is not happening very often. and 
> defragmentation would require moving objects, which is hard 
> to achieve (or 
> impossible).
> what else could be done to reduce excessive growth and 
> fragmentation of the 
> heap? a little example:
> for(int i=0;i<1000;i++)  {
>          AnyClass ref = new AnyClass();
>          ref = null;
> }
> this loop would quickly create 1000 instances of AnyClass on 
> the heap, 
> which are all garbage. if it was possible to tell the gc to 
> dispose certain 
> objects immediately, the same loop would only require room 
> for one instance 
> of the class on the heap.
> for(int i=0;i<1000;i++)  {
>          AnyClass ref = new AnyClass();
>          GarbageCollector.registerForImmediateDisposal(ref);
>          ref = null;
>          int disposalCount = GarbageCollector.runOnDemandGC();
>          if (disposalCount < 1) {
>                  there must be other references to the object
>          }
> }
> would it make sense to give the garbage collector a small 'hintlist' 
> for  certain objects the programmer thinks he does not need 
> anymore, and to 
> run a garbage collection only for those objects on demand?
> norbert
> At 11:04 17.02.2003 -0800, Boehm, Hans wrote:
> >There are some efforts underway to improve this a bit:
> >
> >- I think someone was working on explicitly letting the GC 
> know about 
> >statically allocated pointer variables, so it no longer has 
> to scan static 
> >data segments.  This allows the collector to operate with the same 
> >performance and a smaller heap.
> >
> >- The current version of the GC (not yet merged into gcj) 
> tries to be more 
> >intelligent about finding win32 static data segments, and 
> should thus 
> >avoid scanning more malloc'ed data.  This has a smaller 
> impact, but it may 
> >happen sooner.
> >
> >I believe the gcj collector is not built to allow the heap 
> to shrink.  The 
> >collector itself has some limited support for that.  But 
> since it never 
> >moves objects, it can only unmap pages that happen to be 
> completely empty.
> >
> >You can adjust the heap growth heuristic by changing the 
> value of the C 
> >variable GC_free_space_divisor.  See gc.h for details.  You 
> might check 
> >whether a large value (e.g. 10 or 20) improves matters for you.
> >
> >Hans
> >
> >-----Original Message-----
> >From: Norbert Frese
> >To: java@gcc.gnu.org
> >Sent: 2/17/03 10:11 AM
> >Subject: gcj mingw32 and java memory footprint.
> >
> >Hi!
> >
> >Congratulations to your Mingw32 build of gcj!
> >
> >I have just downloaded the compiler from Mohan Embars site 
> and compiled
> >the
> >SWT-Application i am developing for one of my customers. I 
> was surprised
> >
> >that it works without problems. The .exe is small enough to 
> fit into a
> >~2
> >mb installer. This makes distributing java programs much 
> easier, because
> >
> >the jvm is not required anymore. It is also a great idea to 
> bundle gcj
> >with
> >the swt-library.
> >
> >There is one issue, which seems to be a general java problem:
> >The memory footprint of my application is as bad as with jre 1.4.1
> >(hotspot). My app grows to about 20mb right in the 
> beginning, which is
> >shocking to anyone looking at the task-manager.
> >
> >I guess memory footprint is a general problem of the design 
> of the java
> >language. It encourages people to encapsulate everything  into
> >classes/objects (like events...) and to hope they get cleaned away by
> >the gc.
> >
> >The garbage collector simply does not know when a program needs to be
> >optimized for speed or wants to be lean in terms of memory footprint.
> >For
> >instance it might be good to be fast on Application startup, but then
> >reduce the heap size to give room to other applications.
> >
> >What do you think? Would it make sense to give programmers 
> more control
> >on
> >garbage-collection at runtime. Perhaps with an additional API which
> >allows to
> >
> >* request the imidiate disposal of certain objects. (without 
> running a
> >complete garbage-collection cycle)
> >
> >* telling the heap-mamagement to follow a grow / shrink 
> strategy... (i
> >don't like the idea of limiting the heap to a fixed size).
> >
> >i'm not an expert on the internals of the java runtime, so maybe my
> >suggestions don't make sense at all.
> >
> >best regards,
> >
> >norbert
> 0676-9507806 | NEU: norbertf@gmx.net

More information about the Java mailing list