RE: gcj mingw32 and java memory footprint.

[Norbert Frese <norbertf at gmx dot net>]

thanks! i had a wrong picture of how java garbage collection works. also i 
found out, that the 'memory hunger' of my application was caused by native 
windows objects (loading lots of png images to decorate the swt widgets).

just a theoretical reflection: would it be possible to combine a tracing 
collector with reference counting? as far as i understand, reference 
counting allowes to dispose objects immediately - even for circular 
dependencies (in case the programmer is aware of them and sets them to 
'null'). the tracing collector would just have to clean away the other 
stuff. i assume that a very high percentage of objects used in an average 
java program would get disposed through reference counting right away.

but i guess there is no way to use such model with gcj, because it would 
require a lot of macros for reference copying... and i'm sure there are a 
lot of other problems involved with reference counting which i don't really 
know about... (threads, performance...)

norbert


At 12:49 18.02.2003 -0800, Boehm, Hans wrote:
> 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.
>
> Hans
>
>
> > -----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
> >
> >

0676-9507806 | NEU: norbertf@gmx.net