gcj mingw32 and java memory footprint.

[Norbert Frese]

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