gcj mingw32 and java memory footprint.

Mon Feb 17 19:04:00 GMT 2003

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